Verification Consultant Lauro Rizzatti explains that the three different types of hardware emulator offer different design capacities, thereby giving users more options
Source: EE Times
Unlike software simulators, whose specifications do not mention limits in design capacity, a primary specification of hardware emulators is the maximum size of the designs they can handle. More to the point, different emulators have different limits on design capacity. Why is this?
Let’s first address the concept of design capacity in a software simulation environment. There is a good reason why the vendors of simulators — whether logic simulators at the register transfer level (RTL) and electronic system level (ESL), or gate level, or even analog simulators — don’t specify the maximum capacities of their tools.
A simulator is essentially a software algorithm running on a computer. The algorithm processes data representing a design model described in a design language at one of multiple hierarchical levels as illustrated in Table 1.
Table 1. Design hierarchical levels and corresponding description languages.
The data representing the design model resides on the hard drive of the computer. When the simulator is invoked, that data is moved into the host computer’s memory. If the entire design fits into the physical memory, the user can achieve the maximum speed of execution for that design with the given stimulus and the specific simulator. If the design is too large to fit in the memory, then only portions of the design will be loaded. When the processing of a particular portion is completed, the algorithm swaps out the processed design portion and swaps in the next design portion.
Clearly, the larger the memory, the larger the size of the design portions that can be moved in and out of memory. Two problems that may arise are excessive memory swapping and/or cache misses, both of which can have deleterious effects on the speed of execution.
The bottom line is there is no hard limit to the design size any given software simulator can handle. Rather, when the design size reaches several tens of million gates, the speed of execution may drop to such an extent that it becomes impractical to simulate. Often, designers of high end processors claim simulation performance of less than one cycle-per-second, which is pathetically slow if the user needs to execute many millions of cycles.
Hardware emulators are a completely different matter and — to further complicate the story — not all hardware emulators are created equal. For this analysis, we can divide them into three main classes: processor-based emulators, custom FPGA-based emulators (also called emulators-on-chip), and standard FPGA-based emulators. The first two are based on custom chips; the third is built using arrays of commercial FPGAs.
Regardless of the type, all three emulators have limits in terms of the maximum design sizes they can handle, though there are differences.
A processor-based emulator vaguely resembles a software simulator in that the design database, stored in memory, is processed by a computing engine made up of a vast array of Boolean solvers or processors; hence the name of this emulator type. As in a simulator, the larger the memory, the larger the design the user can process. In a processor-based emulator, unlike a simulator based on a single algorithm (simulators can run in parallel on computer farms, but each computer executes one simulation algorithm), there are ultra large arrays of Boolean solvers running in parallel. This computing scheme allows for a somewhat soft limit in design capacity. A user can slightly exceed the maximum capacity specified by the vendor, maybe by as much as 10 percent, at the expense of a drop in performance that may be significant.
By contrast, both the custom FPGA-based and the standard FPGA-based emulators map the design into the reprogrammable resources of the FPGAs (gate-for-gate, roughly speaking)> The difference between the two arises from their internal architecture (see What’s The Difference Between FPGA And Custom Silicon Emulators?, Electronic Design, April 14, 2014).
The architecture of the custom FPGA used in the emulator-on-chip assures a high level of utilization of the reprogrammable resources, approaching 100 percent before running into routing congestion. Also, this architecture is designed to ease the process of partitioning a large design into a large array of such custom FPGAs. Furthermore, the architecture allows for extremely fast place-and-route (P&R), in the ballpark of five minutes per custom FPGA. However, such a custom FPGA would make a poor choice as a general-purpose FPGA, because the capacity of custom FPGAs is a fraction of that offered by the largest commercial FPGAs. The end result is that the architecture of the custom FPGA perfectly suits the buildup of large arrays of FPGAs as required in a modern emulation platform.
The architecture of a high-end commercial FPGA offers the largest number of reprogrammable resources, but at the tradeoff of P&R processing time. At 90 percent utilization of the reprogrammable resources, a successful compilation without routing congestion may take more than 20 hours. When a commercial FPGA is used as a building block in an emulation platform, the emulator vendor may have to deal with hundreds of these FPGAs. Partitioning and P&R become issues that have to be addressed by the compilation software. Looking at emulator specification sheets, it appears that the utilization of the commercial FPGA is limited to about 50 percent. This helps to dramatically reduce compilation time.
In summary, simulation and emulation are two very different verification tools, each with its own advantages and limitations. Simulator vendors offer no hard data on design size limits, whereas design teams largely judge emulators on design capacity and size. Simulation runs out of steam when it is required to run a large number of gates, while the three different types of hardware emulators offer different design capacities, thereby giving users more options.
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.