Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Examining performance in hardware emulators

Posted: 08 Sep 2015 ?? ?Print Version ?Bookmark and Share

Keywords:hardware emulation? System Verilog? SoC? debugger? in-circuit emulation?

I now wish to discuss one of the most important aspects of hardware emulation: speed of execution. Emulation performance!or its speed of execution!depends on the architecture of the emulation system and the type of deployment. In this first instalment of a two-part series, I wish to discuss the type of deployment; i.e., how the design under test (DUT) and the test environment communicate with each other, managed by the run-time software. In my next column, I will elaborate on the architecture of emulation systems and how this affects performance.

The run-time software
The run-time software controls the environment that drives the DUT. It applies the stimulus, processes the response, and handles all the verification collateral essential for a thorough design verification session of an embedded system-on-chip (SoC) design, the most important being System Verilog assertions (SVAs), monitors, checkers, and functional coverage.

The run-time software embraces two different components as follows:

1. The first component is tasked with bringing the hardware up to life and executing the DUT. This is the combination of the operating system running on the PC and extensive firmware loaded in the emulator. The two, in symbiosis, manage the I/O operations of the DUT mapped inside the platform and enable the user to start, stop, rewind, loop, single-step, save, and restore!all of the standard operations.

2. The second component is the DUT debugger. I will address this important capability in a future post.

Deployment modes
The predecessors of the modern emulators were essentially deployed in only one operational mode called in-circuit emulation (ICE), in which the emulator was plugged into a socket on the physical target system in place of a yet-to-be-built chip so the whole system could be debugged with live data.

ICE posed its own challenges. For one, although an emulator may run up to six orders of magnitude faster than an HDL simulator, it is not fast enough to run at the same speed of a physical target system. To make things work, speed rate adapters must be introduced between the target system and the emulator. A rate adapter behaves like a buffer. It caches the signal activity from the DUT at emulation speed and sends it at real-time speed to the target system. Conversely, it captures the signal activity from the target system at full speed, caches it, and then sends it back to the DUT at emulation speed.

In the old days, the number of peripherals were few and rather simple. Today's SoCs include many complex, high-speed interfaces, each of which would require a rate adapter to be connected to the emulator. Even when a rate adapter is available, the constant evolution of speed and complexity of individual I/O protocols has made timely rate adapter development difficult. A case in point is the evolution of Ethernet routers with an ever increasing number of ports and speeds.

An even more severe drawback of ICE is the lack of deterministic or repeatable behaviour when debugging the DUT. The dependency on physical peripherals introduces a substantial degree of unpredictability of the stimulus such that a design bug may show its effect at different time stamps in two consecutive emulation sessions. Tracing a bug in this erratic environment can be a nightmare.

Another negative is that the physical devices connected to the emulator require manned supervision to connect/disconnect the adapters or to initialise the target system. All of this escalates the complexity of the setup and defeats the deployment of an emulator as a datacenter resource for remote, multi-user access.

While ICE is still in use, emulators are mainly used in other modes of operation. Gathered under the generic term of accelerated verification, there are four modes of deployment characterized by the type of testbench and the type of communication between the testbench and the DUT mapped inside the emulator; specifically:

1. Cycle-based acceleration
2. Transaction-based acceleration
3. Embedded testbench acceleration
4. Embedded software acceleration

The remainder of this column considers these modes in more detail.

Cycle-based acceleration
In cycle-based acceleration, also called co-simulation, the same testbench used in pure simulation is processed by the host workstation and a signal-level or bit-level interface connects it to the DUT loaded onto the emulator. This verification approach is the simplest and the least labour prone when moving from pure simulation to hybrid simulation/emulation, since it leverages the existing simulation testbench and removes the need for external rate adapters required in ICE. Unfortunately, the actual verification speed is severely limited by the performance of the host PC, the complexity of the testbench, and the signal density of the interface between the testbench and the DUT.

1???2???3?Next Page?Last Page

Article Comments - Examining performance in hardware em...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top