A verification plan lists 140 features of a new interconnect. For each one, someone must decide: unit, block, subsystem or chip? Too low, and the feature's real behaviour (with real neighbours, real software) is never seen. Too high, and its corners are never reached. Done carelessly, the same feature is verified three times at three levels while another is verified at none.
How do you decide where each feature is verified?
The obvious rule is "where the feature lives": DCRouter's features at DCRouter's level. That is right for its internal rules and wrong for every feature that involves another block, software or the system: the low-power handshake with the power controller, the driver's initialisation sequence, end-to-end bandwidth. The level is decided by what the bugs need to show up, not by where the RTL sits.
Question | If yes |
|---|---|
Can its bugs be triggered and seen at the block's own interfaces? | Verify at block (or unit) level, completely |
Does it depend on a real neighbour's behaviour, or on several blocks interacting? | Verify the interaction at subsystem level |
Does it depend on software, chip-level configuration, power or clock management, or end-to-end paths? | Verify at chip level, focused on that dependency |
A feature can answer yes to more than one: then each level verifies only the part it alone can see.
Feature | Block | Subsystem | Chip |
|---|---|---|---|
R1–R10 forwarding, arbitration, credits, CRC, counters | Complete (Parts 4–7) | Spot checks with real traffic | Not re-verified |
R11–R12 registers | Complete; formal register app | None | Access from the processor through the bus fabric |
R13 sleep and wake | Rules complete | Wake from real DMA traffic patterns | Power-controller handshake, firmware sequence |
Credit interface to memory controllers | Against a model | With the real controllers | None |
Bandwidth under real traffic | Saturation tests | Real traffic mixes | End-to-end with software workloads (lesson 8.7) |
Feature | Level | Why |
|---|---|---|
Hit, miss, replacement, dirty eviction, tag and state logic | Block, with formal on the state machine | All visible at the cache's interfaces; corners need precise control |
Coherence with other caches | Subsystem (several caches and the interconnect) | Needs real peers issuing conflicting requests |
Coherence with DMA and software cache maintenance | Chip | Needs software and other masters |
Performance (hit rate, latency) on real workloads | Chip or emulation | Needs real programs (Part 10) |
Assign each feature, record the level in the plan, and avoid unowned features at boundaries.
Higher levels verify only the delta: connections, interactions, software, performance.
Reuse lower-level checks higher up rather than writing new ones (lesson 8.3).
Revisit the assignment when bugs escape a level: an escape is a sign the feature needed a higher (or lower) level.
Practice | Purpose |
|---|---|
A level column in the verification plan | Every feature has a home |
Integration test plans listing only cross-block features | Chip effort focused on what blocks cannot see |
Escape analysis by level | Plans corrected when a level missed something (lesson 11.7) |
A team (illustrative) verified a cache's coherence logic only at block level, against a model of the interconnect that delivered snoops one at a time. The real interconnect could deliver a snoop in the same cycle as a fill response. The block environment could never produce that, and no subsystem environment existed; the bug was found on the first multi-core boot. Assigning "snoop and fill together" to subsystem level would have caught it.
The handshake with the power controller and the firmware's power-management sequence: both involve other blocks and software that DCRouter's block testbench does not contain.
Arbitration is proved and tested at block level; the subsystem and chip only check it is connected and behaves sensibly under real traffic, not every corner again.
Assign each feature by what its bugs need to appear: own interfaces, real neighbours, or software and the chip.
Higher levels verify only the delta, reusing lower-level checks.
Record the level for every feature; unowned features at boundaries are where escapes come from.