The Verification Plan
Every technique across Sections A through D — coverage, formal, CDC, linting, GLS, power-aware, timing — answers "is this specific thing correct." None of them, on their own, answer a different, prior question: what actually needs checking in the first place, and how will anyone know when it has been. That's the job of a verification plan — a real document, not an implicit understanding held in engineers' heads.
What it actually contains
A verification plan is a structured mapping from the design's specification to concrete verification artifacts — every feature the spec calls out gets traced to the coverpoints, assertions, and test cases that actually check it, not left as an assumption that "the test suite probably covers this somewhere." At minimum, a real plan names: the feature or requirement being verified, the coverage goal that proves it was exercised, the checking mechanism (scoreboard comparison, an assertion, both), and a status field tracked over the project's life — not written once and forgotten, but a living document the CDV loop and coverage closure process both work against directly.
A worked row: the full adder's overflow behavior
Digital Design's own Number Systems page flagged this exact scenario directly, back at the very start of this site's curriculum: "when you design or verify an adder later in this topic and in Verification, overflow behavior is one of the first things worth explicitly testing, not an edge case to discover by accident." Here's what turning that sentence into an actual verification plan row looks like:
| Feature | Requirement | Coverage goal | Checking mechanism | Status |
|---|---|---|---|---|
| Two's-complement overflow | Adding two positive operands whose true sum exceeds 2ⁿ⁻¹ − 1 must assert the overflow flag, not silently wrap | Cross-coverage bin: both operands positive, result sign bit negative | Scoreboard compares cout/overflow flag against an independently-computed expected value, every cycle | Closed |
Notice what the row forces that a vague "we tested overflow" note wouldn't: a specific coverage bin (not just "overflow was tested," but the exact operand-sign combination that constitutes overflow), a named checking mechanism, and a status that's either genuinely closed or visibly not. A reviewer — or a formal signoff decision, per Coverage Closure — can look at this row and know exactly what evidence backs "overflow is verified," rather than trusting the claim on its own.
Traceability runs in two directions, not one
Everything above describes forward traceability: starting from a spec requirement and tracing it to the coverpoint/assertion/test case that checks it — confirming nothing the spec asked for was missed. A real plan also needs the reverse direction, backward traceability: starting from an existing coverpoint, assertion, or test and tracing it back to the specific requirement it's supposed to be checking. Backward traceability is what catches a different, quieter problem forward traceability alone won't: a coverpoint or test that exists, runs, and even reports "passing," but doesn't actually map to any real requirement anyone asked for — effort spent verifying something nobody needed checked, while a real requirement sits untraced. A complete plan supports tracing in both directions: every requirement to its checks, and every check back to its requirement.
Not every row deserves equal effort: risk-based prioritization
A plan with fifty rows doesn't imply fifty equal shares of verification effort. A real plan also ranks rows by risk — how likely a feature is to actually contain a bug, and how costly that bug would be if it escaped to silicon (directly the same economics The Cost of Bugs made the case for) — and directs the heavier techniques (extensive constrained-random sweeps, formal proofs, more reviewer scrutiny) toward the highest-risk rows first, rather than spreading effort evenly across a list that treats a rarely-exercised debug-only feature the same as the design's core datapath. A plan without this prioritization can technically "cover everything" while still under-verifying the handful of features a real bug would actually be expensive in.
Why this is a document, not a mental model
The forward reference above is itself evidence for why this matters: it was written at the very beginning of this site's curriculum, for a page about number systems, about a DUT (the full adder) that wouldn't get its own testbench for many pages afterward. A verification plan is what lets that connection survive the gap — a requirement identified early doesn't depend on anyone remembering it was mentioned once, chapters earlier, if it's written down as a row someone is accountable for closing.
What's next
A plan names what to verify. The next page covers how a real team actually runs the verification effort day to day against that plan — regression, seed management, and the lifecycle a bug goes through once one is actually found.