A system-on-chip contains hundreds of blocks. A team could verify the whole chip at once, running real software on the full design. That test would be realistic, and it would take hours to boot, see almost nothing inside each block, and reach almost none of each block's corner cases. Or the team could test each block alone: fast, thorough, and blind to how the blocks behave together. Real projects do both, and more levels in between.
Why is a chip verified at several levels, and what is each level good for?
The obvious choice is one level: "test the whole chip, because that is what ships", or "test every block thoroughly, and the chip will work". The first cannot reach corners or debug quickly; the second misses everything that happens between blocks. Each level sees some bugs well and others not at all, so evidence has to be gathered at several.
Level | Speed and visibility | Finds well | Misses |
|---|---|---|---|
Unit | Fastest; every signal visible; formal practical | Corner cases of small logic | Anything involving context |
Block | Fast; full checking at interfaces and inside | Feature bugs, protocol violations, corners | Integration with neighbours |
Subsystem | Moderate | Interactions between closely coupled blocks | Whole-chip effects, software |
SoC | Slow; limited visibility | Connectivity, address maps, interactions, boot | Deep corners of any one block |
System | Real time in the lab | Software, electrical and real-world behaviour | Almost all internal detail |
Lower levels prove features; higher levels prove that features connect and cooperate.
Checks travel up: assertions and monitors written at block level keep running at SoC level (Part 8).
Each level trusts the one below, but only as far as its evidence goes: an SoC test should not retest block corners, and must test what blocks could not see.
Level | Typical owner and method |
|---|---|
Unit and block | Block DV engineers: constrained random, assertions, coverage, formal on control logic |
Subsystem | Integration DV: reuse of block environments, interaction scenarios |
SoC | SoC DV: software-driven tests, connectivity checks, emulation |
System | Validation and silicon teams: real software and boards |
A project (illustrative) skipped subsystem verification between a DMA engine and a memory controller, each thoroughly verified alone. At SoC level, a rare ordering of a DMA write and a controller refresh corrupted data, and took two weeks to reproduce in the slow SoC environment. A subsystem testbench of the two blocks together reproduced it in minutes after the fact, the level where it should have been found first.
At SoC (or subsystem) level: neither block's own testbench contains the shared address map.
SoC simulation is slow and the FIFO's internal state is hard to steer and see there; a unit test or formal proof reaches those corners in seconds.
Each verification level trades speed and visibility against realism.
Prove features at the lowest level that sees them fully; test integration where it first becomes visible.
Reuse checks upward and avoid retesting the same thing at two levels.