Hardware emulation: The most versatile of them all

Today, hardware emulation has become an extremely popular verification tool. Two independent reasons concurred to this success:

1. In the past few years, the emulation user community has expanded exponentially by the addition of software developers to the traditional base of hardware designers and verification engineers. Statistical data shows that the former class of users offset the latter in a ratio of well above five to one.

2. At the same time, uses of hardware emulation have multiplied because of its versatility as a resource for debugging both the hardware and software of complex system-on-chip (SoC) designs. Hardware emulation is the only verification tool that can be deployed in more than one mode. In fact, it can be used in four main modes, some of which can be combined for added versatility. Because of this resourcefulness, hardware emulation can be used to achieve several verification objectives.

Deployment modes vs. verification objectives
Deployment modes are characterized by the type of stimulus applied to the design under test (DUT) mapped inside the emulator. These modes encompass the following:

In-Circuit Emulation (ICE): This was considered to be the traditional method when hardware emulation was deployed. In this case, the DUT is mapped inside the emulator and connected in in-circuit emulation (ICE) mode to the target system in place of a chip or processor for debug prior to silicon availability.

Transaction-Based Acceleration (TBX): Transaction-based emulation moves verification up a level of abstraction from the register transfer level (RTL), improving performance and debug productivity. It's gaining popularity over the ICE mode because the physical target system is replaced by a virtual target system using a hardware verification language (HVL) such as SystemVerilog, SystemC, or C++. By eliminating the need for speed adapters inserted between a slow emulator and a fast target system, several benefits can be achieved. It also offers a way to implement hardware emulation remotely.

Simulation Testbench Acceleration: In this mode, an RTL testbench drives the DUT in the emulator via a programmable logic interface (PLI). In general, this is the slowest performance mode, but it has some advantages, such as the fact that it does not require changes to the testbench.

Embedded Software Acceleration: In this mode, the software code is executed on the DUT processor mapped inside the emulator. This is the fastest performance mode, making it the choice for processing billions of verification cycles necessary to boot an operating system.

It is possible to mix some of the above modes, such as processing embedded software together with a virtual testbench driving the DUT via verification IP or even in ICE mode.

The verification objectives include the following:

Hardware Debugging: This is the foremost application and what hardware emulation is noted for. In addition to offering speed of execution between 100,000X and 1,000,000X (i.e., five and six orders of magnitude faster than hardware description language (HDL) simulators), this is also the most "truthful" verification tool. This is because it provides an accurate representation of the design based on a silicon implementation before actual silicon is released by the foundry.

Hardware/Software Co-verification or Integration: Hardware emulation is the only verification tool able to ensure that embedded system software works as intended with the underling hardware. It can trace a software bug propagating its effects into the hardware and, conversely, a hardware bug manifesting itself in the software's behaviour.