A design verification plan lists every feature of a chip or FPGA block that must be verified, how each will be verified (simulation, formal, emulation), the coverage that proves it, the owner and the status. It turns the spec into measurable goals: functional coverage shows the features were exercised, code coverage shows the RTL was, and regressions plus closed bugs show it works.
- Write the plan from the specification, one row per feature, before writing tests.
- Functional and code coverage answer different questions; sign-off needs both.
- Link every plan row to its tests, coverage items and bugs.
- Waivers need an owner and a reason, recorded in the plan.
What is a design verification plan?
It is the agreement between design and verification on what "verified" means for a block or chip. Each row names a feature from the specification, the method that will verify it, the coverage items that prove it was exercised and who owns it. Reviews of the plan catch missing features before any test is written, and the plan becomes the sign-off checklist at tapeout.
In automotive and mechanical engineering, a "DVP&R" (design verification plan and report) lists physical tests and their results. The chip version below has the same purpose but measures coverage in simulation and formal tools.
Design verification plan template: the columns
Download the design verification plan template (CSV); it opens in Excel or Google Sheets with three fictional rows. The columns:
| Column | What to write |
|---|---|
| Feature ID and spec reference | A stable ID and the spec section it comes from |
| Feature | One verifiable behaviour, written so a reviewer can say yes or no |
| Method | Simulation (directed or constrained random), formal, emulation or lab |
| Stimulus and checker | The sequence or test, and the scoreboard, assertion or reference model that judges it |
| Coverage items and goal | Covergroup bins, cross or assertion cover, and the target (often 100 percent of planned bins) |
| Priority and milestone | Must-have for first silicon, or later |
| Owner and status | One name; not started, in progress, covered, waived |
| Linked bugs and tests | Bug IDs found while verifying it; regression tests that cover it |
Code coverage vs functional coverage: what is the difference?
SystemVerilog supports "writing test benches using coverage, assertions, object-oriented programming, and constrained random verification" (IEEE 1800). The two kinds of coverage answer different questions.
| Code coverage | Functional coverage | |
|---|---|---|
| Question it answers | Which lines, branches, conditions, toggles and FSM states of the RTL ran? | Which features and scenarios from the plan were exercised? |
| Who defines it | The simulator, automatically from the RTL | The verification engineer, as covergroups and assertion covers |
| Blind spot | Cannot see a feature that was never coded | Cannot see RTL that no plan item reaches |
| Typical goal | Close to full, with reviewed exclusions | All planned bins hit, or waived with a reason |
High code coverage with low functional coverage usually means the tests run the RTL without checking the features that matter. The reverse usually means the plan is missing features that exist in the RTL.
How do you reach coverage closure?
Merge coverage from every regression run, then review the holes row by row. For each hole decide: write a directed test, adjust constraints so random tests reach it, prove it with formal, or waive it as unreachable with a reason and an approver. Re-run the merged report after each change and stop only when every planned item is covered or waived.
Verification plan example: a UART block (illustrative)
An illustrative example, not a real project: three rows from the plan for a UART transmitter and receiver.
| ID | Feature | Method and checker | Coverage | Status |
|---|---|---|---|---|
| UART-F01 | Transmits 8N1 frames at each supported baud rate | Constrained random; monitor decodes the line and scoreboard compares bytes | Baud rate by data pattern cross, 100 percent | Covered |
| UART-F07 | Flags a framing error when the stop bit is low | Directed test injects bad stop bits; assertion on error flag | Error flag set for each baud rate | Covered; bug 412 fixed |
| UART-F12 | Receive FIFO overflow sets the overflow flag and drops the byte | Formal property plus one directed test | Assertion cover on overflow | Waived for first silicon by the verification lead; formal proof planned |
Common verification plan mistakes
A plan that is not maintained stops being a sign-off tool.
- Writing features too broadly ("UART works") so nobody can say when they are done.
- Coverage goals with no link to plan rows, so a report at 95 percent says nothing about which features are missing.
- Closing coverage without checkers: a feature exercised but never checked.
- Waivers with no owner, reason or date.
- Not updating the plan when the spec changes, so new features have no rows.
Linking the plan to bugs and regressions
A plan row that lists the bugs found while verifying it, and the regression tests that cover it, lets a reviewer see which features were hard. Over several projects those links show where designs tend to break and which checks found the problems.
Verification plans as a data asset
Plans linked to coverage databases, regression results and closed bugs, kept over several projects, show how a team decided what to test and what it found.
AI developers building chip design and verification tools ask for this kind of linked history from the firms that own it. Where a license is agreed, customer designs, foundry PDK content and third-party IP are removed first, and the export classification is checked before anything leaves the company.
If your company keeps years of design and verification records, the guide for chip and electronics design firms explains what AI developers ask for and who signs. To see what yours could be worth, describe them in six questions; no files or system access needed.
Common questions
What should a design verification plan include?
One row per feature from the spec, with the verification method, stimulus, checker, coverage items and goal, priority, owner, status and linked bugs and tests.
What is the difference between code coverage and functional coverage?
Code coverage measures which parts of the RTL ran and is generated by the simulator. Functional coverage measures which planned features and scenarios were exercised and is written by the verification engineer.
Is 100 percent code coverage enough to sign off a design?
No. It shows the RTL ran, not that the features in the spec were exercised and checked. Sign-off needs functional coverage, passing checkers and reviewed waivers too.
What is coverage closure in verification?
The process of reviewing coverage holes and closing each one with a test, a constraint change, a formal proof or an approved waiver until every planned item is covered or waived.
Who writes the verification plan?
Usually the verification lead, from the specification, reviewed with the designers and architects so that every feature has a row.
Is a DVP&R the same as a chip design verification plan?
They share a purpose. A DVP&R in automotive and mechanical work lists physical tests and their results; a chip verification plan lists features, methods and coverage measured in simulation and formal tools.
How often should the verification plan be updated?
Whenever the specification changes and at every milestone review, so new or changed features always have rows before tests are written.
Sources and further reading
Origin Data Partners is an independent data partner. We work with buyers, and a buyer may pay us when a deal closes.