Using FPGAs For Emulation

For many years, emulators were available only to verification teams working on the largest projects in companies with deep enough pockets. Due to size rather than capabilities they were called “Big Box” emulators and typically were used in order to recover some of the time lost on RTL simulation. Meanwhile, FPGA technology has been available long enough to mature to the point where FPGA based emulation became available – and I’m not talking here about FPGA prototyping.

“Emulation – Prototyping, aren’t they just synonyms?”

No, they are not. The most significant differences between FPGA usage in prototypes and in emulation are shown in table 1.

Table 1: Typical differences between FPGA usage in prototyping and emulation.

FPGAs are the fastest platform for prototyping, but we can also harness that speed into our verification environment, then we can achieve runtime performance 2x to 5x faster than traditional “big box” emulation systems, and all at a fraction of the cost per gate per MHz.

“FPGAs are way too small for our SoC design, aren’t they?”

Aldec already has the largest capacity single FPGA boards commercially available today. Connecting 4 such boards in a backplane gives you 24 largest Xilinx UltraScale chips, in which you can implement 633 Million ASIC Gates and still have 40% of capacity margin to facilitate FPGA place-and-route.

Fig 1: Scalable HES platform for prototyping & emulation.

Not all designs need such excessive capacity, especially IoT projects, where the primary requirement is small footprint and energy-safe design. You will find the proper configuration in Aldec HES boards versatile portfolio containing Virtex-7, Virtex UltraScale and Kintex UltraScale based hardware.

However, raw FPGA resources don’t make an emulator. Power, clocking, memory, connectivity, host interface and other hardware resources also need to be provided and linked efficiently to the verification tools running on the host workstation. The most critical elements of any emulator are the tools and libraries, which make it possible to compile the SoC design into the hardware and then stimulate and debug it when it is there.

“We’re verification guys. We can’t be FPGA experts, as well.”

Good point. We’re on the same page. In the case of an FPGA-based emulator, we should not be dragged into the low-level details of implementation, such as synthesis, constraining timing, mapping clock tree or inter-FPGA I/O configuration and multiplexing. For emulation, we trade off the maximum possible performance and/or resource utilization for automation, ease-of-use and debugging capabilities. Our main aim is simulation acceleration, co-emulation with virtual platform or virtual peripherals but with relatively short turnaround times. If emulation bring-up had taken weeks like prototyping it wouldn’t make sense to use it at the stage where bugs are still very likely to be discovered.

So how do we achieve that automation?

Automation in Aldec’s case is achieved by using HES-DVM. It is software package that provides all the IP libraries, SCE-MI infrastructure and transactors, compilers, partitioner and mappers required in order to automatically integrate HES FPGA platforms with the proven Aldec Riviera-PRO; verification environment and other simulators or virtual platforms such as ARM Fast Models and QEMU as shown in figure 2.

Figure 2: FPGA-based Emulation use modes.

For example, how would you like to hook your FPGA-based emulator into an advanced UVM test bench? HES-DVM includes the necessary SCE-MI infrastructure and transactors compiler to allow UVM drivers and monitors to communicate with the DUT in the emulator. The HES board connects to the host workstation via PCI Express link but you don’t need to develop PCIe device drivers and simulator hooks. Just follow the Accellera’s SCE-MI SV-Connect guideline and develop your UVM drivers and monitors with System Verilog DPI-C functions used as interface and the HES-DVM compiler will convert them to FPGA structures, map to the board and wrap with PCIe driver and link with simulator’s DPI-C. If all those acronyms in the previous sentence need some explaining then take a look into UVM Simulation Acceleration solutions page.

Hybrid Co-Emulation is another use model. Often the CPU subsystem is included as pre-verified RTL IP, and so many of our cycle-accurate verification tests do not need to extend to that RTL. However, we will often need to run software on the CPU subsystem in order to verify its integration with the rest of the SoC, this might be as simple as “bare-metal” code or as complex as the full software stack. In many cases, an untimed Virtual Platform representing the CPU subsystem will be sufficient for these tests, using transaction-level representations and SystemC/TLM standard. The same SCE-MI transactors also allow us to link our FPGA-based emulator to Virtual Models, opening the door to Hybrid Co-Emulation.

Finally, if you are also aiming to create an FPGA-based prototype of your SoC, then an FPGA-based emulator is a great place to start and now with Aldec’s platform you can reuse the same hardware platform for both emulation and prototyping.