A new verification lead inherits a project with 1,800 tests, a coverage database and a spreadsheet called "vplan" that lists test names. Asked what the tests are meant to prove, which requirements are still unverified and when the block will be done, nobody can answer from the spreadsheet. It records what was built, not what was intended. The lead's first job is to write the plan the project never had.
What is a verification plan, and what should it contain?
The obvious plan is a list of tests to write. A test list describes activity, not intent: it cannot show that a requirement has no test, that two tests check the same thing, that a feature needs formal rather than simulation, or what "done" means. A plan starts from what must be true about the design and works down to how each truth will be shown.
Section | Answers | Lessons that feed it |
|---|---|---|
Scope and references | Which design, which specification versions, what is out of scope | Part 2 |
Features and rules | Every requirement, numbered, with its source | Lessons 2.2, 9.2 |
Risk and priority | Which features matter most and are most likely to be wrong | Lesson 9.3 |
Method and level per feature | Directed, random, formal, emulation; block, subsystem or chip | Parts 4, 7, 8 |
Checks and coverage per feature | How a wrong behaviour is detected; how exercise is measured | Parts 5, 6 |
Environment and resources | Testbenches, VIP, models, tools, people | Lesson 8.4 |
Schedule and milestones | What is verified by when; estimates with uncertainty | Lesson 9.4 |
Metrics and done criteria | What evidence closes each feature; what signs off the block | Lessons 9.5, Part 14 |
Change process | How late changes are assessed and re-verified | Lesson 9.7 |
Reader | Needs from the plan |
|---|---|
Verification engineers | What to build and check, in what order |
Designers and architects | Whether their intent was understood: they review the features and rules |
Managers | Effort, schedule and risk, honestly stated |
Sign-off reviewers | The criteria the evidence will be judged against, agreed in advance |
Later teams (derivatives, silicon validation) | What was verified, how, and what was waived |
Traceable: every feature to the specification, every check and bin to a feature (lesson 2.6).
Prioritised: the riskiest features first, not the easiest.
Living: updated as the specification, the design and the findings change; versioned with them.
Measurable: each feature's "done" is a piece of evidence, not an opinion.
Reviewed: by designers and architects before work starts, when corrections are cheap.
Practice | Purpose |
|---|---|
Plans in a structured format linked to coverage and test results | Status computed, not reported by hand |
Plan reviews with design and architecture at the start | Misunderstood intent caught before testbenches are written |
Plan versions tied to specification versions | Changes in intent visible as plan changes |
The opening story (illustrative) is common: a test list that grew for two years with no plan behind it. When the lead mapped tests to the specification, a quarter of the requirements had no test, a third of the tests overlapped heavily, and two features nobody had planned were verified only by accident. Three weeks of planning redirected more effort than the previous three months of test writing.
It lists what exists; a requirement with no test simply does not appear, while a plan starting from the requirements shows it with an empty evidence column.
So the evidence is gathered against criteria everyone accepted, instead of argued over at the end when changing course is expensive.
A plan states intent, method, evidence, priority and done for every feature; a test list only records activity.
It serves engineers, designers, managers, sign-off and later teams at once.
Keep it traceable, prioritised, measurable, reviewed and current.