Verification Consultant Lauro Rizzatti explains why hardware emulation really is the most versatile of verification tools
Source: EE Times
Today, hardware emulation has become an eminently popular verification tool. Two independent reasons concurred to this success:
- 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.
- 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 behavior.
- Embedded Software Validation: Embedded software encompasses different types ranging from drivers to operating systems, applications, diagnostics, and any software-driven tests. They all share one characteristic in that they need to process anywhere from hundreds of millions up to billions of cycles. Emulation can do the job in a reasonable timeframe.
- System-Level Prototyping: Today’s SoC design capacities can easily exceed 100 million gates and, in the processor world, reach over a billion gates. Only hardware emulation can accommodate this level of design size without running out of steam.
- Low-Power (Power Island) Verification: While hardware emulation can’t test analog behavior since it requires a digital representation of the design, it can perform low-power design verification. This is achieved by modeling the switching on/off of power islands and related issues, such as retention, corruption, isolation, and level shifting, as defined in a unified power format (UPF) file.
- Power Estimation: Emulation can track switching activity at the functional level and generate a database to be fed to power estimation tools.
- MBIST Logic and Scan Vectors Verification: Design-for-test (DFT) techniques, such as Memory Built-In Self-Test (MBIST) and scan vectors generated by Automatic Test Pattern Generation (ATPG) tools are essential components of SoC design verification. They are based on very long sequences of test patterns that require powerful processing engines for thorough verification. Hardware emulation is the pre-eminent tool for such compute-intensive tasks.
- Performance Characterization: Design performance characterization in its simplest form can be carried out by counting the number of cycles required for a specific function to be accomplished. A more sophisticated and elegant approach is offered by several electronic design automation (EDA) companies.
And yes, it is possible to carry out a verification objective with one or a combination of the deployment modes.
If we take a survey 12 months from now, the chances are that some clever verification engineer will have found yet another application for hardware emulation. After all, it really is the most versatile of verification tools.
Dr. Lauro Rizzatti is a verification consultant. He was formerly general manager of EVE-USA and its vice president of marketing before Synopsys’ acquisition of EVE. Previously, Lauro held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.