If there is a single largest factor that has driven the evolution of hardware emulation as a primary verification tool, it is system-on-chip (SoC) design. These designs continue to grow in size and functionality and require more IP and interfaces. Emulation technology also caters to the entire SoC development cycle by testing the hardware properties of an SoC design and validating the embedded software in it concurrently; neither simulation or FPGA prototyping tools can fully ensure the hardware/software co-verification.
Figure 1. Complex SoC designs highlight the uphill task of testing peripheral connections and configurations.
However, it wasn’t always like this. Hardware emulators became a popular verification tool in the 1990s, but back then they were hard-to-use clunky equipment that required several months to set up. Moreover, emulation was a single-user resource that cost several million dollars per seat, so only the microprocessor and graphics chip companies with large budgets could afford to buy an emulator.
Then there were issues such as poor reliability and the fact that emulators were mired by slow operations. A serious overhaul was due for emulators, and eventually, the rise of the SoC design movement provided the necessary impetus for emulation tools, making them faster, cheaper, and easier to use.
For a start, advancements in the compile flow reduced the emulation set-up time from months to weeks, if not hours. Next, a new generation of emulation engines significantly accelerated the design compile cycles, run-time speed, and debug cycle times to enhance the overall time to visibility. Within the emulator architecture, there was a shift from expensive custom processors to more flexible FPGAs that made emulation tools more affordable.
The cost of owning an emulator has been reduced the point where more users can now purchase an emulator. In addition, the emulator chassis is now built to fit within the ‘aisle rack’ footprint of a datacenter. Furthermore, modern emulators consume less memory for compiler cycles, and that further reduces the cost and cuts compile time.
From ICE to co-emulation
Another important part of the evolution of hardware emulation is the gradual shift from the traditional in-circuit emulation (ICE) environments to co-emulation techniques like transaction-based verification or acceleration. The ICE mode is usually difficult to install and maintain because the design-under-test (DUT) environment is mapped inside the emulator, which in turn, connects with the physical system where the chip resides via speed adapters.
Figure 2. Transaction-based emulators provide a more flexible test environment for SoC design verification.
The rising amount of functionality in a large multi-clock SoC design results in a greater number of interconnects, and that slows the emulator speed and hinders remote access for multiple users. On the other hand, transaction-centric methods use software-based protocol interfaces, called transactors. These transactors, not the entire DUT setting, are mapped inside the emulator, which inevitably enhances the verifications speed.
That allows both verification engineers and software developers to access the emulation system concurrently from multiple locations. Moreover, transaction-based verification or acceleration counter the unpredictability of the traditional ICE environments by enabling the creation of test benches at a higher level of abstraction with fewer lines of codes. And these test benches execute faster than conventional RTL benches.
However, it’s worth noting that ICE environments boasting hardware interfaces are still required in some applications. So there are versatile emulation tools like the Veloce emulation platform from Mentor that offer a mix of ICE and co-emulation approaches.