Skip to guide

System verification strategy

Turn the specification into evidence

Part 1 · Risk and evidence

Classify the subsystem, anchor the plan to its real standards, and assign each risk to the cheapest trustworthy verification engine.

Keep the source of truth, observation path, stress model, and exit evidence explicit so every verification decision can be reviewed.

Risk + evidence3 focused sectionsNative diagrams + worked reasoning

Primary-source accuracy pass

Anchor the methodology to the real contract.

Protocol, low-power, CDC, UVM, memory-ordering, and closure claims below were checked against standards owners and production open-source verification documentation. Each link opens the governing or implementation-level source.
Accellera · IEEE 1800.2

UVM reference implementation

Factory, events, barriers, components, TLM, RAL, phasing, and other APIs must be interpreted against the active UVM standard and its documented implementation deviations.

Arm · AMBA AXI/ACE

Ordering is scoped, not global

Same-ID ordering depends on channel and destination; AXI does not generally order different IDs, different masters, or reads against writes. The scoreboard must model the actual ordering domain.

AMD · CDC methodology

Metastability is a physical risk

Dynamic phase stress can expose logic assumptions, but it does not simulate analog metastability. Structural review, recognized synchronizers, implementation constraints, and MTBF analysis remain essential.

Accellera · IEEE 1801-2024

Power intent is executable specification

Isolation, supplies, and state retention belong in the power intent model. A power-aware UVM monitor complements UPF-aware verification; it cannot prove physical isolation-cell behavior.

RISC-V · RVWMO

Consistency requires a formal contract

A global shadow memory is not enough by itself. The checker must encode preserved program order, dependencies, fences, atomicity, and the values a load is legally allowed to observe.

OpenTitan · production DV

Traceability makes closure reviewable

The testplan, functional coverage plan, DV architecture, independent checkers, regressions, waivers, and dashboards form one evidence chain—not separate completion percentages.

Layered evidence

Use the cheapest engine that can prove the claim.

A mature strategy does not ask simulation to prove everything. Each engine owns the claims it can observe reliably, and boundary cases are checked independently by more than one mechanism.

Verification evidence ladder

The design risk chooses the engine; the engine does not choose the requirement.

Risk & contractFeature, forbidden state, latency envelope, recovery, and ownership.
Static structureLint, CDC/RDC, reset, clock, UPF, connectivity, and constraint review.
Formal proofProtocol invariants, safety, bounded progress, arbitration, and unreachable states.
SimulationData integrity, legal reordering, asynchronous scenarios, errors, and coverage.
AccelerationLong workloads, real firmware, performance, power sequences, and system integration.
Closure packetTraceability, coverage holes, waivers, bug convergence, stress stability, and residual risk.
  • Independent observation
  • Requirement traceability
  • Reproducible configuration
  • Residual-risk review

Choose the dominant risk

Classify the subsystem before drawing the testbench.

The same UVM building blocks recur, but the source of truth, ordering model, temporal checks, stress dimensions, and sign-off evidence depend on the design family.
Type 01Block level first

Transactional fabric

AXI interconnect · NoC · Cache-coherent fabric

  • Out-of-order matching
  • Multi-agent environment
  • Distributed scoreboard
  • ID-based tracking
  • Latency and QoS coverage
Type 02Block level first

Memory subsystem

DDR controller · Multi-bank SRAM controller · L2 cache

  • Temporal checking
  • Bank and state modeling
  • Address-based prediction
  • Performance coverage
  • Heavy stress debug
Type 03Block level first

High-throughput data engine

DMA · AI accelerator · PCIe or NVMe data mover

  • Bandwidth scoreboarding
  • Outstanding-depth control
  • Backpressure modeling
  • Performance coverage
Type 04Block level first

Coherency or consistency model

ACE or CHI · CPU LSU · Coherent accelerator

  • Global memory model
  • State transitions
  • Commit-time checking
  • Race conditions
  • Silent-data-corruption debug
Type 05Block level first

Control-heavy subsystem

Power controller · Interrupt controller · Reset or clock manager

  • Scenario testing
  • Coverage mapped to the specification
  • Error injection
  • Bring-up and debug methodology