Verification Stages

A complex SoC cannot be verified as a single monolithic unit — the design is too large, too interconnected, and too slow to simulate all at once from day one. Instead, verification is structured in stages, each targeting a different level of the design hierarchy with a different focus and a different set of tests. Understanding these stages and what they are responsible for is fundamental to how verification projects are planned and executed.

10 min read | Beginner Level

What You'll Learn

• The three main verification stages — block, subsystem, and system — and what each targets
• What regression suites look like at each stage and what they are designed to catch
• Why bugs found at later stages are significantly more expensive to fix
• How the stages fit together across a real chip development timeline

Why Stages Exist

When a chip is designed, the RTL is written block by block — a memory controller, an interrupt handler, a DMA engine, a CPU core. Each block is developed by a different engineer or team, often in parallel. Waiting until the entire SoC is assembled before running any simulation would mean discovering bugs only at the point where they are most expensive and slowest to fix.

Staged verification solves this by applying verification at each level of the hierarchy as it becomes available:

Block-Level Verification

Block-level verification — sometimes called unit-level verification — is the first and most intensive stage. Each IP block is verified in isolation: the DUT is a single module, and the testbench provides all the stimulus that would normally come from surrounding logic.

The testbench at this stage is self-contained. It drives the block's inputs directly, checks its outputs, and has no dependency on other blocks being ready. This isolation is valuable: when a test fails, the bug is known to be inside this one block, not buried in an interaction between multiple blocks across the chip.

What Block-Level Verification Targets

• All functional behavior specified for the block — every register, every control signal, every state machine transition
• Interface protocol compliance — if the block has an AXI slave port, every aspect of AXI handshake behavior is verified here
• Corner cases and boundary conditions — counter overflow, FIFO full/empty, reset mid-operation, back-to-back transactions with no gaps
• Error handling — illegal inputs, timeout conditions, error flag generation and clearing
• Reset behavior — every register must reach its specified reset value; the FSM must reach its idle state

Coverage at Block Level

Block-level verification carries the highest coverage requirements of any stage. Code coverage targets of 95–100% are typical, with full functional coverage closure required against the block's verification plan. The reasoning is straightforward: if a bug is not caught here, it will only be discovered later when it is far harder to isolate and fix.

Block-level verification is where the most engineering effort is spent. A well-verified block is a reliable building block — the integration team can focus on interface behavior rather than re-discovering bugs that should have been caught upstream.

Subsystem-Level Verification

Once individual blocks pass their block-level sign-off, they are assembled into larger subsystems — and subsystem-level verification begins. At this stage, the DUT is no longer a single block but a cluster of connected blocks: perhaps a CPU core connected to a cache, a memory controller connected to a DMA engine and an AXI interconnect, or a video pipeline with multiple processing stages.

The focus shifts from internal block behavior to interface behavior between blocks. Block-level verification confirmed that each block handles its own protocol correctly. Integration verification confirms that the blocks work correctly when actually connected and communicating with each other.

What Subsystem-Level Verification Targets

• Inter-block communication — does the AXI master in block A correctly exchange transactions with the AXI slave in block B?
• Shared resource contention — what happens when two blocks simultaneously request access to a shared bus, memory port, or interrupt line?
• Reset sequencing — in a subsystem with multiple reset domains, do the blocks come out of reset in the correct order without deadlocking?
• Datapath integrity across block boundaries — data written by one block and read by another must maintain integrity through the interconnect
• Clock domain crossings (CDC) — signals crossing between blocks clocked by different frequencies must be properly synchronized

A class of bugs is uniquely discoverable at subsystem level: bugs that only manifest when two correctly-behaving blocks interact. Each block passes all its own tests. The bug appears only when they are connected — caused by a subtle mismatch in protocol interpretation, timing assumption, or reset dependency between the two blocks.

Testbench Architecture at Subsystem Level

Integration testbenches are typically assembled from the block-level verification components — the same drivers, monitors, and protocol checkers used at block level are reused at subsystem level, now driving the subsystem's external interfaces rather than individual block ports. This reuse is one of the key reasons industry methodologies like UVM invest heavily in modular, reusable testbench components.

System-Level / SoC Verification

System-level verification operates on the full chip — all subsystems assembled together, running realistic end-to-end scenarios. At this point, the simulation model includes processors, memory controllers, peripheral IP blocks, DMA engines, interrupt controllers, and all the interconnect that ties them together.

The nature of testing changes significantly at this stage. RTL simulation becomes very slow for a full SoC — billions of clock cycles are needed to run a realistic software stack. System-level verification therefore relies more heavily on emulation for software bring-up and FPGA prototyping for real-interface testing, while RTL simulation is reserved for targeted scenarios that cannot be run elsewhere. See Verification Techniques for a detailed comparison.

What System-Level Verification Targets

• End-to-end functional scenarios — a full DMA transfer from a peripheral to system memory, an interrupt being raised and serviced by the CPU, a boot sequence completing successfully
• Software and firmware behavior — device drivers, firmware initialization sequences, and OS-level interactions are exercised for the first time in the full chip context
• Performance — throughput, latency, and bandwidth measurements under realistic workloads; performance regressions are caught before tapeout
• Power behavior — power domain transitions, clock gating, retention register behavior during sleep/wake sequences
• Multi-block interactions at scale — scenarios involving many blocks simultaneously, such as a network packet being received, processed by a CPU, written to memory, and transmitted through a different interface

Regression Suites at Each Stage

At every verification stage, the tests that have been developed are organized into a regression suite — a curated set of tests that is run automatically whenever the RTL changes. Regression suites serve as a safety net: any RTL change that breaks a previously passing scenario is caught immediately rather than silently accumulating.

The character of each regression suite reflects the stage it belongs to:

• Block-level regression: Thousands of tests, dominated by constrained random seeds. Runs nightly on a compute farm. Covers the full functional coverage model for the block. Any new RTL commit triggers at minimum a smoke regression — a fast subset of the most critical directed tests — before the full nightly regression runs.
• Subsystem-level regression: Smaller test count than block level, focused on inter-block integration scenarios and interface compliance. Tests are typically longer in simulation time than block-level tests because they exercise multi-block transaction sequences.
• System-level regression: The smallest number of tests but the longest simulation time per test. Focuses on end-to-end scenarios, boot sequences, and performance benchmarks. Often supplemented by emulation runs that cannot be tracked by the RTL simulation regression infrastructure.