Doing ESL system validation using transactors

Using an emulator for ASIC and System-on-chip, verification holds the promise of extremely high execution speed, enabling the validation of system-level scenarios that are unthinkable with simulation farms.

With MHz speeds, today's fast emulators can crunch enough cycles to run entire software application stacks on top of an SOC and truly perform hardware software co-verification. However, having a fast and accurate model of the ASIC solves only half of the problem. Without the corresponding system-level environment to drive the design, that potential is wasted.

In-Circuit Emulation: At a fraction of the speed
Historically, the first emulators, as well as FPGA prototypes, have been deployed in in-circuit emulation (ICE) mode. By connecting to real target devices (the target system), it was believed that the behavior of the system would be as accurate as possible.

However, since the emulated design would only run at a fraction of the speed of the actual silicon, speed bridges had to be inserted to adapt traffic between the live devices running at real speed and the design executed at lower speed.

The different speed domains broke the timing relationships between the test environment (live devices) and the emulated design, thus preventing the testing of many critical scenarios such as corner cases, burst accesses, etc. The verification team had the false impression that the design was functional, only to discover that after tape-out problems remained.

By and far, the above is not the only drawback of an ICE deployment. Setting up the test environment requires the designing and manufacturing of adapters that may suit only one target system.

Every time the designers would want to verify the design-under-test (DUT) against a slightly different target system, it would involve new adapters or at best plugging and unplugging daughter-cards. Quickly it becomes annoying to swap modules to test a video display chip with a landscape LCD and a portrait LCD.

Whenever a change is made to one physical platform, that change needs to be duplicated on all hardware setups. No surprise, verification engineers cut corners and limit the scope of their physical platform to the smallest convenient subset, hurting verification results and letting critical bugs through.

Hardware dependencies such as timing hazards, noise and RF susceptibility plague the reliability of the test environment and frustrate the verification engineer. Debugging a DUT via ICE is rather different from using a simulator.

Since clocks are generated in the target system, they cannot be controlled, therefore only hardware triggers and logic analyzers can be used. Even worse, since the ICE environment behaves non-deterministically, it defeats the repeatability of execution runs.

The ICE environment cannot be managed remotely since it requires the assistance of an operator to physically connect the emulator to the target systems. Maintaining an ICE environment is all but easy since hardware updates can be hard if not impossible to implement.

All of the above drawbacks led to the quest for a virtual platform that would preserve accuracy, even in the most obscure scenarios, offer speed, scalability, controllability, repeatability, remote access and be as easy to use as a Verilog simulator.

Click here to read more ...