How to Build a Strong Verification Plan
In short: A verification plan is the map for the whole effort. It lists every feature to check, ranks them by risk, matches each to the right stimulus and technique, and ties coverage goals and a schedule to them so problems appear early. Read the spec first, blend random, directed, and environment-driven stimulus, track coverage and bug counts, and revise the plan as you learn.
A verification plan is the map for the whole verification effort. A clear one helps a design reach production with the bugs found and fixed early. A weak one leads to missed deadlines, costly rework, and sometimes a recall. This post explains why the plan matters and walks through the steps to build one that holds up.
Why a verification plan matters
The plan does three jobs. It makes sure every feature and function is covered, by listing each one and the test cases that will check it. It keeps the effort efficient, by ordering the most important features first and matching each to the right technique. And it tracks progress, by tying a schedule and coverage numbers to each feature so trouble shows up early instead of at the end.
Key steps for creating the plan
Start by reading the specification closely so you know the required features, along with the performance and reliability targets. From that, list the features to verify, ranked by how complex and how critical each one is and by the resources you have. Then decide how you will drive each feature and how you will check the result, and set a schedule with coverage goals you can track. Treat the plan as a living document: revise it as findings come in and priorities shift.
Ways to generate stimulus
Most plans mix several styles of stimulus rather than relying on one. The three you meet most often are random, directed, and environment-driven, and each has a clear place.
| Stimulus type | How it works | Best for |
|---|---|---|
| Constrained-random | Legal random values within set rules | Broad coverage and finding surprises |
| Directed | Hand-written for a specific scenario | Must-pass cases and known corners |
| Environment-driven | Modeled from the real surroundings | Realistic, system-level traffic |
Use a mix of verification techniques
No single technique covers everything. A good plan reaches for the right one per job and often combines them.
| Technique | What it does well |
|---|---|
| Simulation | General functional checking with waveforms |
| Emulation | Fast runs of large designs and real software |
| Formal | Proving a property always holds on control logic |
| Mixed-signal | Checking analog and digital together |
Track progress and iterate
As runs pile up, watch the coverage of each feature and the count of bugs found and fixed. Falling coverage or a spike in new bugs is an early warning. Use it to re-order the remaining work. The plan is never finished on day one; you refine it as the design and the schedule teach you more.
A simple way to picture it
Think of planning a long road trip. You do not just start driving. You look at the map, decide which stops matter most, pick the right roads for each stretch, and pack for the conditions. Along the way you check your progress against the plan and reroute when a road is closed. A verification plan is that map for a chip: it tells you where to go, in what order, and how to know you are on track.
Common mistakes
- Starting to write tests before the specification is fully understood.
- Listing features without ranking them by risk and importance.
- Leaning on one stimulus style or one technique for everything.
- Setting no coverage goals, so progress cannot be measured.
- Freezing the plan and never revising it as findings arrive.
Key takeaways
- The plan makes coverage, efficiency, and progress visible.
- Read the spec, list and rank features, then map techniques to them.
- Blend random, directed, and environment-driven stimulus.
- Track coverage and bug counts to catch trouble early.
- Keep the plan alive and revise it as the project moves.
This is general guidance on planning rather than a template tied to one company or tool. Adapt the steps, techniques, and coverage goals to the design, schedule, and resources of your own project, and ask experienced colleagues to review the draft.
Keep learning
A plan is only as good as the thinking behind it, so the notes on the thought process in verification and how a verifier thinks like a verification engineer pair well here. To fill in the technique side of the plan, see assertions, coverage metrics, and when a hard bug appears, an orderly approach to solving complex issues.
Frequently asked questions
What is a verification plan?
It is the document that maps the whole verification effort: the features to check, the test cases and techniques for each, and the schedule and coverage goals used to track progress.
Why is a verification plan important?
It ensures every feature is covered, keeps the effort efficient by ordering work by importance, and makes progress visible so problems surface early instead of near tape-out.
What are the main steps to build one?
Understand the specification, list and rank the features to verify, choose stimulus and checking for each, set a schedule with coverage goals, and iterate as findings come in.
What types of stimulus should the plan use?
A mix works best: constrained-random for broad coverage and surprises, directed for must-pass corners, and environment-driven for realistic system-level traffic.
Which verification techniques belong in a plan?
Simulation for general checking, emulation for large designs and software, formal for proving control properties, and mixed-signal where analog and digital meet.
Should a verification plan ever change?
Yes. It is a living document. As coverage data and new bugs arrive, you re-order the remaining work and refine the plan rather than freezing it on day one.
