Writing a Simple Verification Plan
Turn a specification into features to check, corner cases, verification methods, and completion criteria.
Verify the specification, not just the code
A verification plan starts from the specification rather than the RTL implementation. If the same requirement is misunderstood in both design and testbench, comparing one with the other will not expose the mistake.
Read requirements independently and record unclear points before writing tests. A sentence such as "the result is valid after processing" needs details: after how many cycles, what happens when the receiver is not ready, and must the result remain stable?
One row per verifiable feature
A simple plan can use a table:
| Feature | Scenarios | Check | Coverage | Priority |
|---|---|---|---|---|
| Reset | startup, reset while active | expected outputs and state | each useful interruption point | high |
| Transfer | nominal, waits, bursts | protocol scoreboard | lengths crossed with waits | high |
| Error | overflow, illegal command | error code and absence of forbidden effect | each error | medium |
Each row should connect to a directed test, a random constraint, an assertion, or a coverage point. A requirement with no check is not actually verified.
Five testbench jobs
A complete environment must:
- generate transactions;
- apply them to the DUT;
- observe inputs and outputs;
- compare behavior with a reference;
- measure what has been exercised.
A small project may implement these jobs with a few tasks. A larger environment uses separate components. The plan is the same.
Nominal, boundary, and error cases
For each feature, consider:
- one normal case that is easy to diagnose;
- minimum and maximum values;
- consecutive operations with no gap;
- simultaneous commands;
- reset interruptions;
- illegal inputs and their expected response.
Random stimulus helps combine these situations, but it does not replace directed cases that quickly prove basic functions.
A concrete completion criterion
"Run many cycles" is not a completion criterion. Verification can close when:
- all mandatory tests pass;
- assertions report no unresolved failures;
- planned coverage points are reached or justified;
- known bugs have a documented decision;
- no important requirement remains unchecked.
Coverage tells you what was exercised, not whether the result was correct. Read it together with functional checks.
Key points
- The plan comes from requirements and stays independent of RTL.
- Each feature needs scenarios, a check, and a measurement.
- Boundary cases and reset belong in the initial plan.
- Random stimulus complements directed tests.
- Verification closes with measurable criteria and explained gaps.
📝 Test your knowledge - Chapter quiz