A verification plan — commonly called a Vplan — is the foundational document that defines what gets verified, how it gets verified, and what criteria determine when verification is complete. Written before a single testbench file exists, it acts as a contract between the design and verification teams for the entire project lifecycle.
Without a Vplan, verification becomes reactive — engineers write tests for whatever they happen to think of, coverage gaps go unnoticed until late in the project, and there is no objective standard for declaring the design ready for tapeout. The Vplan prevents this by making verification a planned, measurable engineering activity.
10 min read | Intermediate Level
What You'll Learn
- What a verification plan contains and why each section matters
- How to extract verifiable features from a design specification
- How the Vplan drives coverage goals and sign-off criteria
- How to structure a Vplan for a real block-level verification project
Why Write a Verification Plan First?
A common mistake for engineers new to verification is to start writing testbench code immediately after receiving the design specification. This produces tests that reflect what the engineer remembers to check rather than a systematic analysis of the design's features and risks.
The Vplan forces a structured upfront analysis: reading the specification thoroughly, identifying every feature that must be exercised, estimating the effort required, and agreeing on pass/fail criteria before any simulation runs. This investment pays back significantly during coverage closure and sign-off, when teams without a plan often discover entire feature categories were never tested.
The Vplan is also a communication tool. It is reviewed and approved by both the design team and verification team, ensuring shared understanding of what the design is supposed to do and what "verified" actually means for this project.
Contents of a Verification Plan
While the exact format varies between companies and projects, a well-structured Vplan covers these core areas:
1. Design Overview and Scope
A brief description of the Design Under Test (DUT) — its function, key interfaces, and the boundaries of what this verification effort covers. For a block-level Vplan, this defines which block is being verified and which blocks are being modeled as stubs or BFMs (Bus Functional Models).
Scope is critical: it explicitly states what is not being verified in this plan, preventing misunderstandings about responsibility between teams working on different blocks.
2. Features to be Verified
This is the most technically demanding section of the Vplan. Each feature listed in the design specification must be mapped to one or more verification scenarios. Feature categories typically include:
- Functional behavior: Does each described function operate correctly under normal conditions?
- Interface protocols: Are all handshake sequences, burst modes, and protocol corner cases exercised?
- Error handling: Does the block respond correctly to illegal inputs, timeout conditions, and protocol violations?
- Configuration and modes: Are all operating modes and register-controlled behaviors tested?
- Corner cases: Boundary conditions such as counter overflow, FIFO full/empty, and back-to-back transactions.
When extracting features from a specification, treat every "shall" statement as a verification requirement. Each behavioral requirement is something that can be tested and must appear somewhere in the Vplan.
3. Verification Methodology
This section describes the overall approach: directed testing, constrained random verification (CRV), formal verification, or a combination. For most block-level projects, CRV is the primary methodology with directed tests targeting specific corner cases and formal verification used for critical control logic or protocol checkers.
The methodology section also specifies the testbench architecture — whether the environment follows UVM, a custom structured methodology, or a simpler self-checking approach — and identifies any Verification IP (VIP) being reused for standard interfaces.
4. Test Plan
The test plan enumerates specific test scenarios derived from the feature list. Each test entry typically captures:
- Test name and a brief description of what scenario it covers
- Which features or specification requirements it targets
- Whether the test is directed or random (with constraint description)
- Pass/fail criteria — what the scoreboard checks and what constitutes a failure
- Priority (critical path, high, medium, low)
Quick Check
Q: A design spec says "the FIFO shall assert full when it contains 64 entries." How many test scenarios might this single requirement generate in the Vplan?
Show Answer
At minimum two: (1) verify full asserts exactly when the 64th entry is written — not at 63 or 65 — and (2) verify full deasserts correctly when a read occurs. A thorough Vplan would also add: back-to-back writes hitting full, simultaneous read/write at full condition, and reset behavior when full is asserted.
5. Coverage Plan
Coverage is the metric that tells you whether your tests are actually exercising the features you planned. The Vplan defines two types of coverage goals:
Code coverage targets are collected automatically by the simulator — statement, branch, expression, toggle, and FSM coverage. A typical target is 90–95% for non-waived code. The Vplan should note any blocks expected to have legitimate coverage waivers, such as unreachable error handlers or synthesis-only attributes.
Functional coverage targets are defined manually using SystemVerilog covergroups and coverpoints. The Vplan specifies which design scenarios must be explicitly measured — for example, all combinations of burst length and transfer direction for a memory interface, or all FSM state transitions for a control block. These cannot be inferred from code coverage alone.
Code coverage tells you which lines of RTL ran. Functional coverage tells you which scenarios were exercised. Both are necessary — a design can have 100% code coverage while entire valid transaction sequences were never tested.
6. Sign-off Criteria
Sign-off criteria define the measurable conditions that must be met before the block can be released for integration. Typical criteria include:
- All code coverage metrics above the agreed threshold (e.g., 90% statement, 85% branch)
- All functional covergroups closed to 100% or waived with justification
- Zero open bugs of severity "critical" or "blocker"
- All assertion checks passing — no unwaived assertion failures
- Full regression suite passing for the final RTL revision
Defining these criteria upfront, before verification begins, prevents the common end-of-project negotiation where teams argue about what "done" means under schedule pressure.
7. Resource and Schedule Estimate
The Vplan records the estimated engineering effort in person-weeks, identifies dependencies on other teams (such as waiting for a design specification to stabilize or for VIP delivery), and maps key milestones to the project schedule. No estimate is perfect, and most project timelines build in contingency — typically 20–30% — to account for unexpected bug complexity or specification changes.
The Plan Review Process
A draft Vplan is never sent straight to execution. It goes through one or more review cycles involving the design engineer who owns the block, the verification lead, and often a senior engineer who checks for coverage gaps and methodology alignment.
Review feedback typically surfaces issues like: features present in the specification but missing from the feature list, coverage goals set unrealistically high or too low for the block's risk profile, test priorities that don't align with the known high-risk areas of the design, and ambiguous pass/fail criteria that would make sign-off subjective.
A Vplan that has not been reviewed by the design team is a risk. The verification engineer's interpretation of the specification may differ from the designer's intent. Catching this misalignment during plan review costs far less than discovering it after months of simulation.
Multiple revision rounds are normal. The Vplan is a living document — it gets updated as the specification changes, as new corner cases are discovered during simulation, and as schedule constraints force re-prioritization of test scenarios.
Vplan Example Structure
Below is a concrete example showing how a Vplan entry maps a specification requirement to a verification scenario for a simple UART transmitter block:
// =====================================================================
// Vplan Entry Example (documented as a comment for illustration)
// Block: UART Transmitter
// =====================================================================
//
// Feature ID : TX-04
// Feature : Parity Generation
// Spec Ref : Section 3.2.1
// Description: Transmitter shall append a parity bit after the data
// frame. Parity mode (even/odd/none) is configured via
// the PARITY_CFG register field [1:0].
//
// Verification Scenarios:
// TX-04-A : Even parity — verify parity bit is 0 when data has
// even number of 1s, and 1 when odd number of 1s.
// TX-04-B : Odd parity — verify inverse of even parity behavior.
// TX-04-C : No parity — verify no extra bit is transmitted and
// frame length matches 8-bit expectation.
// TX-04-D : Switch parity mode mid-stream — verify reconfiguration
// takes effect on the next frame boundary, not mid-frame.
//
// Test Type : Constrained random (TX-04-A/B), Directed (TX-04-C/D)
// Coverage : Coverpoint on PARITY_CFG[1:0] x data[7:0] cross
// Pass Criteria: Scoreboard compares captured serial output against
// reference parity model for each transmitted byte.
// Priority : High
// Effort : 1.5 days
In a real Vplan, this information lives in a spreadsheet or a structured document tool — not in RTL comments — but the structure above illustrates how each feature maps to concrete test scenarios, coverage measurements, and pass criteria.
Quick Check
Q: Feature TX-04-D tests switching parity mode mid-stream. Is this a directed test or a constrained random test, and why?
Show Answer
Directed. Configuration register changes mid-stream during active transmission represent a specific timing corner case that random stimulus is unlikely to hit naturally. Directed tests are the right tool for precisely timed sequences involving configuration changes.
Common Mistakes in Verification Planning
Mistake #1: Writing the Vplan after testbench development has already started.
Wrong: Starting to build the testbench immediately after reading the spec, then writing the Vplan to describe what was already built.
Right: Completing the Vplan — feature list, test scenarios, coverage goals, sign-off criteria — before writing a single line of testbench code.
Why? The Vplan drives testbench architecture decisions. If it is written after the fact, it describes the tests already written rather than performing a systematic analysis of the spec. Entire feature categories can be missed, and there is no baseline to measure coverage gaps against.
Mistake #2: Listing features without defining pass/fail criteria for each one.
Wrong: Vplan entry reads "Verify FIFO full behavior" with no description of what correct behavior looks like or how the scoreboard decides pass or fail.
Right: Vplan entry specifies "The full flag must assert exactly when the 64th entry is written and deassert on the next read. Scoreboard compares full against a reference occupancy counter at every clock edge."
Why? Without explicit pass criteria, two engineers may run the same test and reach different conclusions about whether it passed. Vague entries also make scoreboard implementation ambiguous and sign-off discussions subjective.
Mistake #3: Setting coverage goals without tracing them back to specification requirements.
Wrong: Adding a covergroup that samples random data values and burst lengths with no connection to what the design spec actually requires to be exercised.
Right: Every coverpoint maps to a specific feature in the feature list — for example, a cross coverage point on transfer direction × burst length traces back to the spec requirement that all combinations of burst mode must be supported.
Why? Untethered coverage goals create the illusion of progress. A team can close 100% of a covergroup that was never meaningful, while the scenarios that actually matter remain untested.
Practice Exercise
Challenge: Write a Vplan Feature Entry
Consider a simple 4-deep synchronous FIFO with the following specification requirement: "The FIFO shall assert the almost_full flag when 3 or more entries are occupied. The threshold is fixed at 3."
Write a Vplan entry for this feature. Include: a feature description, at least 3 test scenarios (give each a name and describe what it checks), the test type for each (directed or random), and a pass/fail criterion.
Hint
Think about the boundary transitions: what happens exactly at 2 entries (flag should be 0) and exactly at 3 entries (flag should be 1)? Also consider: what happens if entries are read back out while almost_full is asserted?
Sample Solution
Feature: FIFO Almost-Full Flag
Spec Ref: Section 2.3
Scenarios:
- AF-01 (Directed): Write exactly 3 entries — verify
almost_fullasserts on the 3rd write. Write a 4th entry — verify flag remains asserted at full. - AF-02 (Directed): Write 3 entries, then read 1 — verify
almost_fulldeasserts when occupancy drops back to 2. - AF-03 (Random): Random write/read sequences — verify
almost_fulltracks occupancy correctly across all transitions, never asserting at 2 or fewer entries, never deasserted at 3 or more.
Pass Criteria: Scoreboard tracks write/read counts to maintain a reference occupancy counter. almost_full must equal (occupancy >= 3) at all times. Any mismatch is a failure.
Summary
In this tutorial, you learned:
- A verification plan defines what gets verified, how, and to what standard — written before any testbench code
- The core sections are: design scope, feature list, methodology, test plan, coverage plan, sign-off criteria, and resource estimates
- Each feature in the specification should map to one or more concrete test scenarios with explicit pass/fail criteria
- Functional coverage goals must be defined in the Vplan — they cannot be inferred from code coverage alone
- Plan reviews with the design team are essential to catch specification misunderstandings before simulation begins
- The Vplan is a living document that evolves as the specification and project schedule change
