Enhancing conventional FPGA-based prototype boards
Conventional FPGA-based prototype boards are usually equipped with a J-Connector, which is intended to allow the prototype board to be connected to external devices. The proposed approach involves the creation of a special interface card that plugs into this J-Connector and acts as a bridge between the host workstation and the FPGA-based prototype board as illustrated in Figure 4.
Figure 4. Adding an interface card and some soft IP.
All communication between the FPGA-based prototype board and the workstation could be implemented using some dedicated buses that would provide the high throughput required for emulation, co-emulation, and co-simulation. By means of this interconnect technology, users would have the flexibility to configure and use different prototype boards with the same J-Connector. This capability also means that users would have the ability to quickly and easily transition to faster and bigger FPGA-based prototype boards, and it would completely remove the limitations associated with conventional hardware-assisted verification solutions.
Observe the soft IP blocks illustrated in Figure 4. These IP blocks would be downloaded into each of the FPGAs on the prototype board and would then be used to control and monitor the data flow between the FPGA-based prototype board and the workstation. Depending on the mode of operation (in-circuit emulation, co-emulation, or co-simulation), appropriate "flavors" of these IP blocks would be automatically inserted as required. These IP blocks, which would be compiled into the design, would also be used to monitor any signals specified by the user. In this way, data from thousands of signals and millions of simulation cycles could be captured and analyzed.
In addition to the interconnect technologies, specialized software that runs on the workstation as illustrated in Figure 5 is needed to perform a number of functions, such as automating the setup of prototype boards containing multiple FPGAs. The setup process includes reading the RTL representation of the design (in VHDL, Verilog, SystemVerilog, or a mixture of these languages), analyzing the design for memory that would be internal and external to the FPGAs, taking the SoC clocks and generating hold-time-free equivalents for use in the FPGAs, partitioning the RTL for the full SoC design to implement it across multiple FPGAs, and instrumenting the RTL with the soft IP blocks and the signals to be monitored.
Figure 5. Adding special software running on the workstation.
During a verification run, software would control and manage communication and data flow between the FPGA-based prototype board and workstation based on the mode of operation specified during setup (in-circuit emulation, co-emulation, or co-simulation). The ability to modify the signals being captured is also key, such that multiple signals could be quickly and easily added without the need to recompile the entire design. Last but certainly not least, visibility into the internal states of the FPGAs on the prototype board, including registers and memory outputs, provided on a snapshot or cycle-by-cycle basis would be useful for advanced debugging.
'Desktop' verification of design prototypes
In order to more fully understand the various capabilities and use models enabled by the interconnect and software automation technologies discussed in this paper, let's consider some example scenarios. The simplest case is a pure in-circuit emulation application as illustrated in Figure 6. The software running on the desktop workstation automatically partitions the design and prepares the prototype board. During the setup process, all necessary probes are instrumented into the design so that the specified signal data is captured during runtime.
Figure 6. An example in-circuit emulation scenario.
Optionally, the user could use the Siloti Visibility Automation System to help determine the minimum set of signals that need to be observed. Also, the Verdi Automated Debug System could be employed to analyze and debug the results from the FPGA-based hardware prototype board. Since the setup software automatically correlates any gate-level signals to their corresponding RTL counterparts, the Verdi system works with the RTL source code to speed the debugging process.
In the case of co-emulation, which speeds the verification process by hundreds or thousands of times as compared to a software-only simulation, a common scenario has the testbench (and possibly a portion of the design) residing on the workstation, while the bulk (or all) of the design is loaded into the prototyping board. The software running on the workstation automatically partitions the design, automates setup of the prototype board, and inserts the appropriate co-emulation infrastructure (such as SCEMI-based transactors). As in the previous scenario, all necessary probes are instrumented into the design during setup enabling the specified signal data to be captured during runtime. Optionally, the co-emulation could be paused and software employed to provide full visibility into the internal states of the FPGAs on a snapshot or cycle-by-cycle basis when needed as illustrated in Figure 7.
Figure 7. An example co-emulation scenario.
Now, let’s explore the co-simulation use model, which speeds the verification process by tens of times as compared to a software-only simulation. Once again, the testbench (and possibly a portion of the design) resides on the workstation, while the bulk (or all) of the design is loaded into the prototype board. In this scenario, the software running on the workstation automatically partitions the design, sets up the prototype board, and generates the wrapper to which the software simulator will link. During runtime, the software orchestrates the co-simulation interaction between the prototype board and an industry-standard software simulator, such as ModelSim, NC, or VCS simulator. As discussed earlier with the other scenarios, visibility into the internal states of the FPGAs on the prototype board, including registers and memory outputs, on a snapshot or cycle-by-cycle basis is achieved through the combination of software and internal FPGA technologies as illustrated in Figure 8.
Figure 8. An example co-simulation scenario.
Advantages of a next-generation prototype verification platform
Shrinking market windows and time-to-market pressures are putting tremendous demands on today's SoC design and verification teams. Software simulation provides 100% visibility into the design, but is applicable only to small portions of the design or to a few tens of clock cycles for the full design. However, it can take hundreds of thousands or millions of clock cycles to fully verify a modern SoC, in which case some form of hardware-assisted verification is required. There are a wide variety of hardware-assisted verification solutions with different capabilities, strengths, and weaknesses. A high-level comparison of hardware-assisted verification technologies is provided in Table 1.
Conventional hardware accelerators and emulators provide large capacity, relatively fast compile times, and reasonably good visibility into the design. However, these systems are too costly to deploy broadly, and difficult to upgrade to the next generation in timely fashion given the high cost of transition. By comparison, conventional FPGA-based prototype boards offer high performance and are relatively inexpensive. However, they lack the design visibility and sophisticated debug capabilities needed to address the complexities of today’s SoCs, and typically can be used only in an in-circuit emulation mode.
Table 1. Comparison of hardware-assisted verification technologies.
In order to address these issues, we’ve proposed a paradigm shift in SoC verification that turns conventional FPGA-based prototype boards into desktop accelerators/emulators. This requires innovative interconnect technologies capable of providing a universal connection to both off-the-shelf and custom-designed boards and specialized software automation that runs on workstations in in-circuit emulation, co-emulation, and co-simulation modes with a high-level of design visibility.
Using FPGA-based prototype boards augmented with these capabilities, SoC developers could quickly verify that individual blocks (including internal and third-party IP blocks) and design modules are functioning correctly, all the way up to the full SoC design. This next-generation prototype verification platform has the potential to maximize the return on investment and productivity of FPGA-based prototype boards, while providing greater verification efficiency and the flexibility to quickly transition to boards equipped with the latest FPGA technologies.
About the author
Howard Mao is the Senior Director in charge of SpringSoft's ProtoLink product line. Prior to joining SpringSoft, Howard worked with Mentor Graphics in Taiwan holding various positions from technical support to sales/marketing and general management. He also served as an assistant researcher for CSIST in the VLSI design area.
Howard holds both B.S. and M.S. degrees in Electronic Engineering from National Chiao-Tung University in Hsinchu Taiwan.