The SoC containing DCRouter is compiled onto an emulator. The same RTL that ran at a thousand cycles a second in simulation now runs at around a million. The operating system boots in an hour and a half instead of two months. Then the team plugs in the UVM testbench used at chip level, and the speed drops back to a few thousand cycles a second: the testbench still runs on a workstation, and every cycle waits for it.
What do emulators do well, and what do they do badly?
The obvious picture of an emulator is "very fast simulation": put the design on it and everything speeds up. Only the part mapped onto the emulator speeds up. Anything left on a host computer (a testbench, a reference model, a debug probe waiting for data) runs at host speed, and if the two exchange information every cycle, the emulator waits. Getting emulation speed means designing the verification for it.
Emulators do well | Emulators do badly |
|---|---|
Run the full RTL at around a million cycles per second (fact V12) | Run anything left on the host at host speed |
Boot OSs and run software before silicon | Analogue, mixed-signal and some memories (modelled instead) |
Offer much of simulation's visibility (signal capture, triggers) | Fast turnaround: compiling a large design takes hours |
Run long random tests to find rare corners | Cost: expensive, shared hardware with queues |
Connect to real-world interfaces through speed adapters | Exact timing of the real silicon (the design runs at emulator speed) |
Synthesisable parts run on the emulator: drivers and monitors written as hardware (transactors) run at emulator speed.
Communicate in transactions, not signals: the host sends a whole packet, the emulator side expands it into cycles; this is what keeps the host out of every cycle.
Embedded software as stimulus: tests running on the chip's processor need no host at all (lesson 8.5).
Checkers in the design: assertions synthesised onto the emulator check at full speed (lesson 8.3).
Step | Concern |
|---|---|
Compile and map the RTL | Non-synthesisable constructs, memories, clocks; hours per compile |
Replace analogue and special blocks | Models for PHYs, PLLs, analogue; behavioural memories |
Connect stimulus | Transactors, software, or speed adapters to real devices |
Plan debug | Which signals to capture, triggers, how deep a history (lesson 10.6) |
Validate the emulation build against simulation | Run the same short tests on both and compare |
Practice | Purpose |
|---|---|
Emulation for OS boot, driver bring-up and long software runs | Software-scale questions answered before tape-out |
Transaction-based testbenches (accelerated verification) | Simulation-style tests at emulator speed |
Long random and soak runs | Rare corners and long-running bugs found |
Power and performance analysis on real workloads | Activity data from billions of cycles (lesson 8.7) |
The opening story is the classic disappointment: a signal-level testbench connected to an emulator ran barely faster than simulation. Rewriting the drivers as synthesisable transactors that exchange whole packets with the host restored most of the speed. An emulator is only as fast as the slowest thing in its cycle loop.
The testbench ran on the host and exchanged signals every cycle, so the emulator waited for the host on each cycle.
Analogue or mixed-signal blocks such as PHYs and PLLs, and some memories.
Emulators run the full RTL around a million cycles per second, with much of simulation's visibility.
Anything left on the host runs at host speed: use transactors, transactions and embedded software.
Plan emulation as its own environment, with models, stimulus and debug designed for it.