Hardware emulators are versatile and can verify designs with full visibility for thorough debugging.
Source: Electronic Design
Engineers often turn to two tools to verify their complex SoC designs: hardware emulation and FPGA prototyping. Some verification teams will use one over the other, while other teams remain confused about their differences and are looking for answers. Electronic Design called upon two experts to sort out the confusion. Below is verification expert Dr. Lauro Rizzatti’s case for hardware emulation. For the counterpoint case made for FPGA prototyping, see S2C chariman and chief technology officer Mon-Ren Chene’s “Today’s FPGA Prototyping—Breaking the Typecast Mold.”
Dr. Lauro Rizzatti, Verification Consultant
If you peek inside a verification toolbox supporting modern system-on-chip (SoC) design development, you will notice a garden variety of point tools and verification methodologies. Each aims at unearthing even the most difficult-to-find bug, whether in the embedded software or in the underlying hardware.
Two of those tools have a prime spot in the tool box—hardware emulation and FPGA prototypes. Both have been around for more than three decades, ever since the first reprogrammable hardware devices were launched into the marketplace. For most of that time, they have been confined to testing the most complex designs when software-based simulators had a hard time completing the task. This is certainly true for validation embedded software, but 10 years ago embedded designs were a novelty.
Today, some people may contend that the two approaches are competing for the same application. I strongly disagree. Instead, I believe they complement each other rather effectively.
A Look at Hardware Emulation
It seems that the EDA industry has settled on three emulation architectures, each favored by one of the three main EDA players: processor-based, promoted by Cadence in the Palladium family; custom FPGA-based, championed by Mentor Graphics in the Veloce family; and standard FPGA-based, adopted by EVE, and perpetuated by Synopsys after it acquired EVE in 2012.
However, regardless of the architecture, and at least from 30,000 feet, they look alike, a similarity enforced by all three vendors claiming somewhat comparable capabilities.
All emulators can map any design size, even in excess of a billion gates. This cannot be said of the FPGA prototype, typically limited to at most two-hundred-million gates. They can reach a maximum performance in the low single-digit megahertz. This is the main difference with the FPGA proto board, considering that proto boards can run at tens of megahertz.
Emulators can verify designs with full visibility for thorough debugging. While debugging differences exist among implementations, vis-à-vis the FPGA prototype, they pale in comparison. The relevance of full visibility comes into play when engineering teams composed of hardware engineers and software developers verify hardware and software simultaneously, which is essential for integrating the two components.
Another significant difference between an emulator and an FPGA prototype is the deployment mode. Some of the latter offer an interface to a software or virtual testbench running on the host workstation, not actively pushed by the vendor because of the slowdown in execution speed from several tens of megahertz to one or thereabouts. Instead, an emulator can be used in several modes.
In in-circuit emulation (ICE) mode, a physical target system in which the design under test (DUT) will reside once it’s taped out, provides stimulus and processes the response. An emulator may replace a physical target system with an equivalent virtual testbed written at a high-level of abstraction. The latter drives the DUT via interfaces implemented by transactors.
Transactors are synthesizable software models of protocol interfaces that communicate with the virtual target system via untimed packets of information and with the DUT via bit-level signals. Since transactors can be mapped inside the hardware emulator, they execute at the maximum speed of the emulator.
Transaction-based emulation appeals to engineering teams because it doesn’t require that a technician be on call –– a practical consideration if it’s a shared resource. Remote users can log in while other users swap designs without the need for manual intervention, such as required when plugging or unplugging speed adapters.
Hardware emulation can be used as a design data-center resource, enabled by resource management software and available to any number of global users. Emulation enterprise servers support numerous configurations of large and small designs. By contrast, the FPGA prototype only supports single users at a far inferior cost than that of a fully configured emulator.
The following table summarizes differences between hardware emulation and FPGA-prototyping.
The chart below maps differences between a typical hardware emulator and a typical FPGA prototype based on performance, setup/compile time, design capacity and design debug (see the figure).
The chart maps differences between a typical hardware emulator and a typical FPGA prototype based on performance, setup/compile time, design capacity, and design debug.
Today, more and more hardware emulation is considered a universal verification tool that can be used throughout the SoC development cycle in virtually all segments, save analog, of the semiconductor industry.
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, he held positions in management, product marketing, technical marketing, and engineering. He can be reached at lauro@rizzatti.com.