Every DCRouter testbench in this course drives the router's own pins directly: any packet, any timing, any register write, every cycle. Now place DCRouter inside a chip: its inputs come from four DMA engines, its outputs go to memory controllers, and its registers are written by firmware on a processor. Reaching the state where all four inputs send length-15 packets to output 0 means programming four DMA engines through software. The bug is the same; the cost of reaching it is not.
Why verify at several levels, and what does each level see?
One obvious answer is "verify at chip level, because that is what ships". It is realistic and painfully slow: simulations run thousands of times slower, every block's corners must be reached through its neighbours and software, and failures are hard to localise. The opposite answer, "block level only", is fast and blind to integration: the neighbours were modelled by the verifier's assumptions (lesson 1.5). Each level sees what the others cannot.
Level | What it is | Strength | Weakness |
|---|---|---|---|
Unit | A small module (a FIFO, an arbiter), often by its designer | Very fast; full control; formal works well | Sees nothing of the block's interactions |
Block | A complete IP such as DCRouter, with its interfaces driven by agents | Fast; every corner controllable; precise checks | Neighbours are models, written from assumptions |
Subsystem | Several blocks together (DCRouter with its DMA engines and memory controllers) | Real interactions between neighbours | Slower; less control over each block's corners |
Chip (SoC) | Everything, with processors running software | Real integration, real software, real configuration | Slowest; hardest to control and debug; long runs |
Bug or risk | Cheapest level | Why |
|---|---|---|
The 24 Bug Zoo bugs | Block (and unit for FIFO and arbiter) | All visible at DCRouter's pins; every corner is one testbench line away |
A DMA engine that drops valid mid-packet, which DCRouter does not tolerate | Subsystem | A disagreement between two real blocks; block models of each were written by different people |
Firmware that enables low power before the credits are initialised | Chip | A sequence across software and hardware no block test contains |
The sleeping output not connected to the power controller | Chip, or a connectivity check (lesson 7.7) | A wiring fact that exists only at integration |
Find each bug at the lowest level that can see it: lower levels are faster, more controllable and easier to debug.
Use higher levels for what only they can see: interactions, integration, software, end-to-end performance.
Do not repeat lower-level work higher up: a chip test that re-verifies FIFO corners wastes the slowest cycles there are.
Carry checks upward: assertions and monitors from block level keep working inside the chip (lesson 8.3).
Practice | Purpose |
|---|---|
Block-level environments for every IP, with sign-off criteria | Corners closed where they are cheap |
Subsystem environments for tightly coupled blocks | Interactions verified before the full chip exists |
SoC tests focused on integration, flows and software | Chip cycles spent on what only the chip shows (lesson 8.5) |
A team (illustrative) skipped block-level verification of a small interrupt aggregator, reasoning that SoC tests would exercise it. They did, for the common cases. A corner, two interrupts asserted in the same cycle from different domains, needed precise timing that no software-driven test could produce reliably, and it was found in the lab. A one-day block testbench would have reached it in minutes.
Each block's own testbench uses a model of the other written from assumptions; the disagreement only appears when the two real blocks are connected.
The block testbench already reaches them in a fraction of the time with full control; chip cycles are slow and should go to integration and software.
Unit, block, subsystem and chip levels trade speed and control against realism.
Find each bug at the lowest level that can see it.
Spend chip-level effort on integration, software and end-to-end behaviour, and carry block checks upward.