Emulation in FPGA

Krzysztof Szczur, Hardware Verification Products Manager
Like(1)  Comments  (0)

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?”


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




Clock frequency

10-200 MHz

1-20 MHz

Clock Topology


Multiple asynchronous sources -  limited number of domains

Derived from emulation core clock - unlimited number of domains

Speed Limitation

Determined by Inter-FPGA signal multiplexing

Determined by FPGA-to-Host Comms, Inter-FPGA signal multiplexing

Stimulus Source

Real-world IO

Connection with simulators, virtual platforms, virtual models and other testbenches

Signal Capture

Selected Nodes

Full Visibility

Memory Models


Near-match to physical


Design Setup

Computer aided but with extensive user’s input and decisions

Fully automated

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?”


In the HES-US-2640 board, 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 & Route.

fpga emulation, fpga emulator, fpga blog Figure 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. Years of experience have allowed Aldec to achieve exactly that, but the most critical elements of any emulator are the tools and libraries; making 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.

fpga emulation, fpga emulator, fpga blog

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.


Think you can’t afford emulation? Think again!

Krzysztof joined Aldec in 2001 and was a key member of the team that developed HES-DVM™, Aldec's FPGA-based simulation acceleration and emulation technology. He has worked in the fields of HDL IP-core verification, testbench automation and design verification for DO-254 compliance gaining practical experience and deep understanding of design verification methodologies, emulation and physical prototyping. As Hardware Verification Products Manager, Krzysztof cooperates with key customers and Aldec's R&D to overcome complex design verification challenges using Aldec hardware tools and solutions. Krzysztof graduated as M.Eng. in Electronic Engineering (EE) at the AGH University of Science and Technology in Krakow, Poland

  • Products:
  • ハードウェア・アシステッド・ベリフィケーション


Ask Us a Question
Ask Us a Question
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.