DCRouter's verification so far produced an environment with drivers and sinks, a per-flow scoreboard, seven pin assertions, an arbitration checker, a 78-bin coverage model and designer-owned formal properties. In an SoC, nobody drives DCRouter's pins: DMA engines do. Most of that work could be thrown away and rewritten for the chip, or most of it could keep running inside the chip, checking DCRouter in its real surroundings for free.
What block-level verification can be reused at higher levels, and how?
The obvious view is that block testbenches are scaffolding, discarded once the block is integrated, since the chip has its own tests. That throws away the most precise checks the project owns, exactly when bugs become hardest to localise. A chip-level failure that a reused DCRouter assertion flags at the router's pins, naming the rule, saves days compared with a wrong result at the end of a software test.
Asset | Reused at higher levels? | How |
|---|---|---|
Assertions inside the design (designer and formal properties) | They travel with the RTL | Simulation assertions run in every chip test; properties under |
Interface assertions and protocol checkers | Yes | Bound or instantiated on the same interfaces in the chip |
Monitors | Yes | Passive: they only observe pins |
Scoreboards | Yes, if fed by monitors | Predictions from monitored inputs, not from drivers (lesson 5.4) |
Coverage models | Yes | Sampled from monitors; shows what the chip tests exercised in the block |
Register models | Yes | The same model, accessed through the chip's bus |
Drivers, sinks, sequences | Mostly no | Real neighbours replace them; some sequences become software or virtual sequences |
dcr_sva.svh: once wrapped in a checker module and bound to the DCRouter instance, its pin assertions for R1, R8, R12 and R13 (quiet while asleep, wake) run unchanged in every chip test; the R13 sleep-timing assertion counts idle cycles from the block testbench's own queues and must first be rewritten to use monitored pins. The formal properties travel inside dcrouter.sv but sit under ifdef FORMAL, so they run in formal, not in chip simulation, unless also compiled with a simulation define.
The scoreboard, once it decodes predictions from monitored flits (below): every packet through the router in a software test is checked.
The coverage model: reveals which router situations software tests reach; holes stay assigned to block level.
Not reusable as is: queue_pkt(), timing knobs and the sinks' drain rates, replaced by real DMA engines and memory controllers.
One change is needed first, and it is instructive. DCRouter's environment predicts at the moment a flit is accepted (in_vld and in_rdy), which is right, but it takes each flit's destination and expected error flag from its own driver's record of the packet. At chip level there is no driver record. A reusable scoreboard decodes both from the monitored flits instead: the destination from the header, the error flag by recomputing the CRC and checking the length. Designing for reuse means predicting from what the pins show, not from what the testbench intended.
Practice | Purpose |
|---|---|
Agents with active and passive modes (UVM) | The same agent drives at block level and only monitors at chip level |
Assertion and coverage libraries per interface | Written once, used at every level and in every project |
Block scoreboards enabled in subsystem and chip tests | Precise, localised failures in slow, large tests |
A team (illustrative) wrote block scoreboards that predicted from their drivers' transaction objects instead of from monitors. At chip level there were no drivers, so the scoreboards had nothing to predict from and were disabled. A chip-level bug in one block surfaced as a corrupted file system in a software test and took a week to trace back. Monitor-fed scoreboards would have flagged the block's wrong output on the cycle it happened.
Assertions written purely on DCRouter's pins (most of dcr_sva.svh). Not quite all: the R13 timing assertion reads the block testbench's queues, and the formal properties inside dcrouter.sv travel with the RTL but run only in formal.
Which router situations the chip's software tests actually reach; holes there show what integration testing never exercised.
Passive verification assets travel up the hierarchy: assertions, monitors, scoreboards, coverage, register models.
Active parts (drivers, sinks) are replaced by real neighbours and software.
Predict from monitors so scoreboards keep working without drivers.