Overview

A Verification Test Plan is a specification document that captures the details needed to verify a given hardware design. It is typically developed by a verification engineer who understands the Design Under Test (DUT), and it is used to plan verification work so that verification can be completed with high quality and within a predictable time period.

A test plan starts from the design specification, also called an architecture or microarchitecture specification. That specification acts as the golden reference for verification and should describe the design implementation, supported features, interfaces and protocols, configuration and initialization information including registers, and other relevant details.

What the plan captures

A verification test plan should list the design features to be verified. Each feature should be briefly explained as an individual test-plan item. The plan should also list supported design configurations under which those features must be tested. Not every feature or configuration necessarily needs its own standalone test; many features and configurations are verified in combination.

The plan can also capture specific microarchitectural cases that must be checked for correctness. Examples include interface properties, internal microarchitectural events such as state machines, FIFOs, arbitration, and interactions between logical blocks. It may also include stimulus patterns, interactions, high-level usage scenarios, and potential deadlock or livelock conditions.

Verification approach

After identifying what must be verified, the plan should describe how each item will be verified. The evidence describes simulation with constrained-random or coverage-driven approaches as the majority approach for functional verification, while selective areas or special features may also use formal verification or other techniques.

The plan should document the intended stimulus infrastructure, randomization controls, sequences, tests, and checking mechanisms. Checking mechanisms may include scoreboards, interface assertions, or embedded assertions in RTL or verification components. A good plan documents both what to verify and how to verify, including testbench components, hierarchy, and stimulus patterns, so that the plan can be translated into implementation with fewer execution issues.

Relationship to coverage

The test plan is closely related to coverage planning. It should translate verification intent into stimulus and coverage properties that help measure stimulus quality and completeness. In the Ibex RISC-V verification example described in the evidence, the testbench stimulates the core to execute programs stored in memory, compares the core trace log against a golden Spike ISS trace log, collects coverage on executed instructions and operands, and uses a test plan and coverage plan to ensure coverage of relevant instructions and operations.

CPU verification plans

For CPU verification, a single test plan is often insufficient. The evidence describes multiple plan types:

• Architecture verification plan: verifies compliance with the instruction-set architecture so software can run correctly. It should cover instructions, modes, memory management, interrupts, and other software interfaces.
• Microarchitecture verification plans: cover logical building blocks such as fetch, execution, load/store, cache, or other IP/block-level units. These plans describe block features, stimulus generation, checking mechanisms, and verification details.
• Performance verification plan: focuses on performance aspects and bottlenecks, using patterns or benchmarks such as SPECint, lmbench, or Dhrystone.

In the Ibex example, the test plan scope includes RV32IMCB instructions, privileged specification compliance, exception and interrupt testing, and Debug Mode operation. The described co-simulation system can run a RISC-V ISS, currently Spike, in lockstep with the Ibex core, checking executed instructions and generated memory transactions against the ISS behavior.