A verification plan is not a list of tests. It is an evidence model: a traceable account of what the design must do, how each obligation will be observed, what will detect a violation, and what evidence is required before closure. Tests are only one way to produce that evidence.
Start with atomic requirements
Specifications often mix behavior, timing, error handling, configurability, and performance in one paragraph. Split that prose into reviewable requirements with stable identifiers. Each requirement should state the operating context, triggering condition, expected result, and permitted exceptions. Ambiguous requirements belong in an issue tracker; they should not be silently interpreted by the testbench.
For every requirement, record five things: stimulus, observability, checker, coverage, and owner. Stimulus explains how relevant state can be reached. Observability identifies the architectural or interface signal that exposes the result. The checker defines pass and fail. Coverage records that the obligation was exercised or proven. Ownership names the person responsible for closure.
Plan by risk, not only by hierarchy
A module tree is useful for assigning work, but it is not a complete risk model. Cross-cutting behavior such as reset, power state, privilege, error recovery, ordering, and clock-domain interaction can span several blocks. Maintain a feature view alongside the structural view so subsystem behavior does not disappear between block plans.
- Interface compliance: legal traffic, illegal traffic, backpressure, ordering, and error responses.
- State and configuration: reset values, legal transitions, access control, and dynamic reconfiguration.
- Data integrity: transformation, storage, forwarding, and end-to-end comparison.
- Recovery behavior: timeout, retry, cancellation, poison, and partial failure.
- Integration behavior: clock, reset, power, interrupt, and software-visible interactions.
Choose the evidence deliberately
Directed simulation is efficient for crisp examples. Constrained-random simulation explores combinations. Assertions monitor temporal contracts. Formal analysis can exhaustively explore a bounded model or prove a safety property under stated assumptions. Emulation and prototypes provide system-scale execution. Assign each obligation to the least expensive technique that can produce convincing evidence.
Coverage should point back to requirements. Code coverage can expose unexecuted implementation, but it does not establish that specified behavior was checked. Functional coverage describes intended scenarios, assertion coverage describes property activity, and formal results describe proof obligations. None substitutes for reviewing whether the requirement itself is complete.
Define closure before execution
Closure criteria should be written while the plan is reviewed, not while a milestone is slipping. Define which checks must pass, which coverage goals require review, how exclusions are approved, what constitutes a stable regression, and which unresolved issues may be accepted. Version the plan with the specification and RTL so scope changes are visible.
Sign-off is a reviewed argument supported by evidence, not a dashboard color.
The final package should let an independent reviewer follow a requirement to its tests or properties, results, coverage, exclusions, and open risks. If that path is difficult to reconstruct, the programme has execution data but not sign-off evidence.
Primary references
Need help applying these methods to a verification programme? Start a technical conversation.