Verification Planning

UVM Testbench Architecture · Module 3 · Page 3.7

The Engineering Problem

You can architect a layered, reusable UVM environment. But an environment is a capability — it can drive stimulus and check results. It does not tell you what to verify or when you are done. Those answers come from a document you write before and alongside the environment: the verification plan. Without it, "done" defaults to "the schedule ended," and "what we tested" defaults to "whatever we happened to write" — neither of which is engineering.

The verification plan is the spine that turns a capable environment into a directed, measurable, sign-off-grade effort. Derived from the specification, it lists every feature and, for each, defines how it will be stimulated, how it will be checked, and how it will be measured by coverage — creating an unbroken chain of traceability from a requirement to the test that exercised it and the coverage bin that proves it. The plan is what makes the layered environment of the previous chapter aim at something: it says which scenarios to write, which checks to apply, and what coverage defines completion. This chapter is the practical discipline of building that plan and wiring it into the environment.

How do you derive a verification plan from the spec, turn each feature into concrete stimulus, checks, and coverage with full traceability, and make that plan the spine that drives the environment and defines sign-off?

Motivation — why the plan, not the environment, is the spine

A verification plan is the difference between activity and accountable engineering:

• It defines "done" as a measurable statement. With a plan, sign-off is "every high-risk feature's coverage is closed and its checks pass," not "we ran out of time." The plan converts completion from a feeling into a number tied to specific features.
• It makes verification traceable and defensible. When someone asks "is feature X verified?", a plan answers with a chain — the requirement, the coverage that proves it happened, the test that exercised it, the result — not an opinion. Traceability is what lets a sign-off survive review.
• It directs the layered environment. The plan tells you which scenarios to write (scenario layer), what to check (functional layer), and what coverage to model — so the environment's effort is aimed at the spec's features, not scattered. The plan is the requirements the environment implements.
• It is risk-ranked, so effort goes where it matters. Not all features carry equal risk; the plan prioritises, so the team closes the safety- and sign-off-critical items first and justifies (rather than brute-forces) the long tail. Planning is where verification economics (Module 1.3) become operational.

The motivation, in one line: the environment is how you verify, but the plan is what you verify and when you're done — and without it, a powerful environment is an aimless one.

Mental Model

Hold the verification plan as a contract derived from the spec:

The verification plan is a contract that translates every spec requirement into three obligations: make it happen, judge it, and prove it happened. You read the specification as a list of features, and for each feature you write three commitments — a stimulus obligation (how will we exercise this? which scenario/sequence?), a check obligation (how will we know it's correct? which assertion or scoreboard?), and a coverage obligation (how will we know we exercised it? which coverage point?). The plan is the sum of these commitments, risk-ranked, with each traceable back to its spec requirement. Building the environment is fulfilling the contract; sign-off is certifying it is fulfilled. And because the contract is derived from the spec, when the spec changes the contract must change — a plan that no longer matches the spec is a contract for the wrong product.

So when you plan, work feature-by-feature from the spec and ask the three questions for each: how do I make this happen, how do I check it, how do I prove I exercised it? The plan is just those answers, organised and traceable — and kept in sync with the spec it came from.

Visual Explanation — the anatomy of a plan entry

Every verification-plan entry has the same shape: a spec feature, decomposed into the stimulus that exercises it, the checks that judge it, and the coverage that proves it — with a risk rank and a traceability link.

The three-obligation shape is the plan's discipline. Stimulus answers "how do we exercise this feature?" — naming the scenarios (scenario layer) or directed tests that create the situation. Checks answer "how do we know it's correct?" — naming the assertions or scoreboard comparisons (functional layer) that judge it. Coverage answers "how do we know we exercised it?" — naming the coverage points whose closure proves the feature was reached. Each is tied to the feature, and the feature to a spec requirement, so every line of verification effort has a traceable reason to exist. A plan entry missing the coverage obligation can't prove it ran; one missing the check obligation exercises without judging; one missing the stimulus obligation is a wish. All three, for every feature, is the contract.

RTL / Simulation Perspective — the plan made executable

The plan is not just prose — its coverage obligations become real covergroups, so closure is measured automatically. Each bin is a plan item, annotated with the requirement it proves.

// Verification plan feature F3 "Burst length": exercise zero, small, and max lengths.
// Feature F5 "Length × direction": every length must occur with both read and write.
covergroup burst_cov @(sample_ev);
  cp_len: coverpoint txn.len {
    bins zero  = {0};          // F3.1 — boundary, high risk: MUST hit
    bins small = {[1:4]};      // F3.2
    bins large = {[5:16]};     // F3.3
  }
  cp_dir: coverpoint txn.write;
  x_len_dir: cross cp_len, cp_dir;   // F5 — the interaction the plan requires
endgroup

This is the bridge from plan to environment. The prose plan says "F3: exercise zero, small, and max burst lengths; F5: cross length with direction" — and that becomes the burst_cov covergroup, with each bin carrying the feature ID it implements. Now closure is measured: when cp_len.zero reads a hit, plan item F3.1 is satisfied; when the x_len_dir cross fills, F5 is satisfied. The covergroup is the plan in executable form, which is what makes sign-off objective — you are not asserting "we covered the burst lengths," you are pointing at a coverage report whose bins map one-to-one to plan features. The stimulus obligations become sequences (scenario layer) that drive toward these bins, and the check obligations become scoreboard/assertion code — so the whole layered environment is the plan, implemented.

Verification Perspective — deriving the plan and ranking by risk

A plan is derived from the spec, feature by feature, and ranked by risk so effort is spent where failure is most costly. The derivation is a disciplined reading of the specification, not a brainstorm.

Two disciplines make the derivation sound. First, derive from the spec, not the implementation. The plan must cover what the specification requires, so that a feature the RTL under-builds still appears as an unfilled planned coverage item rather than a silent absence (the failure of Module 1.10). Reading the spec — including its corner cases, modes, and error conditions — is the source of the feature list. Second, rank by risk. Verification is never exhaustive, so the plan orders features by the cost of their failure: safety-critical behaviour, sign-off-critical paths, and complex interactions get closed first and most thoroughly, while the low-risk tail is explicitly justified rather than brute-forced to a vanity 100%. The risk-ranked, spec-derived plan is what then drives the environment — every scenario, check, and covergroup exists to fulfil a plan entry.

Runtime / Execution Flow — traceability and closure

The plan's runtime payoff is traceability: an unbroken chain from each requirement to the result that proves it, and closure measured against the plan rather than the calendar. This chain is what makes a sign-off defensible.

This chain is the plan working as a spine. Traceability means every requirement can be followed to its proof — plan item, coverage bin, test, result — so "is feature X verified?" has a documented answer, and an auditor (or a tape-out review) can verify the claim rather than trust it. Closure is the loop on the right: you measure coverage against the plan, and unfilled high-risk items direct the next round of stimulus (a new scenario, a directed test, a tighter constraint) until the required items are closed. Sign-off is the loop's legitimate exit — the plan's required coverage is hit and its checks pass — which is a defensible statement about the spec's features, not a statement about the clock. The plan is what gives both traceability and closure a definition.

Waveform Perspective — plan items closing as stimulus runs

The plan's coverage obligations close at run time as stimulus exercises them. The waveform shows the connection: as transactions run, the coverage bins that are plan items get hit, each hit a step toward plan closure.

The bin_small and bin_large pulses are plan items closing in real time. This is the concrete link between the plan (a document) and the run (an execution): the plan named "exercise small and large burst lengths" as features F3.2 and F3.3; the covergroup turned them into bins; and now stimulus hits those bins, each hit recorded as progress. Sign-off is reached when the plan's required bins are all hit — and note that the high-risk boundary bin zero (F3.1) isn't shown hitting here, so the plan is not yet closed; the closure loop would direct stimulus to that gap. The waveform makes the abstraction tangible: planning is what gives these coverage bins meaning, and their hits are what make "done" measurable.

DebugLab — closed 100% against a plan the spec had outgrown

spec v1.0:    N features   → plan v1.0 covers all N   → closed 100% ✓
ECO (spec v1.1): adds 'low-power retention' (feature N+1)
plan:         still v1.0   → feature N+1 NOT a plan item, NOT a coverage bin, NOT a test
closure:      100% of plan v1.0  ← of the OLD spec
reality:      retention mode unplanned, unstimulated, uncovered → escaped to silicon
fix:          re-derive/update the plan on every spec change; version plan against spec

Common Mistakes

• No verification plan at all. Without a spec-derived plan, "done" is "the schedule ended" and "what we tested" is undefined. The plan is the spine; skipping it makes a capable environment aimless.
• Deriving the plan from the RTL instead of the spec. A plan built from the implementation inherits its blind spots — an under-built spec feature vanishes instead of appearing as an unfilled planned item. Derive from the specification.
• Letting the plan go stale. The plan is a living document; if the spec changes (ECOs, revisions) and the plan doesn't, closure is measured against the wrong target. Re-derive and version on every spec change.
• Missing one of the three obligations. A feature with stimulus and coverage but no check exercises without judging; with checks but no coverage, you can't prove it ran. Every feature needs all three: stimulus, checks, coverage.
• No traceability. If you can't link a requirement to the coverage and test that prove it, you have results but no defensible argument. Maintain the requirement → plan → coverage → test → result chain.
• Closure as a vanity 100%, not risk-ranked. Chasing 100% of every bin wastes effort on the low-risk tail while treating it as equal to safety-critical features. Rank by risk; close the critical items fully and justify the tail.

Senior Design Review Notes

Interview Insights

Exercises

1. Write a plan entry. For the spec feature "the FIFO must assert full exactly when occupancy reaches depth," write the three obligations: the stimulus to exercise it, the check to judge it, and the coverage point to prove it — plus a one-line risk justification.
2. Spec vs RTL derivation. Explain why a plan derived from the RTL would have missed a spec-required low-power mode that the design under-implemented, and what deriving from the spec changes.
3. Diagnose the stale plan. A team reports "100% coverage closure, signed off," yet a spec feature failed in silicon. Give the one question that exposes the cause and the process change that prevents it.
4. Trace it. Pick any feature and write its full traceability chain (requirement → plan item → coverage → test → result). Identify which link, if missing, would make the feature's verification unprovable.

Summary

• A verification plan is a spec-derived document that, for every feature, defines three obligations — stimulus (how exercised), checks (how judged), and coverage (how proven) — risk-ranked and traceable to the spec. It is the spine that turns a capable environment into a directed, accountable effort.
• The plan is made executable: its coverage obligations become covergroups whose bins map one-to-one to features, so closure is measured objectively, and its stimulus and check obligations become the scenarios and scoreboard/assertion code of the layered environment.
• It is derived from the spec, not the RTL (so under-built features appear as unfilled planned items), and risk-ranked (so effort goes to the costly-to-fail features first, the tail justified rather than brute-forced).
• Traceability (requirement → plan item → coverage → test → result) makes verification status auditable, and closure against the current spec — not the calendar — is the definition of done. A stale plan certifies the wrong product, so the plan is a living document, re-derived and versioned on every spec change.
• The durable rule of thumb: write the plan from the spec before you trust the environment, give every feature stimulus + checks + coverage with a traceable link, rank by risk, and keep the plan current — because sign-off is plan closure against today's spec, not the deadline.

Next — UVM Environment Mental Model: you can now architect, layer, and plan a verification environment. The final chapter of this module consolidates it into a single mental model of the UVM environment — how architecture, data flow, reuse, layering, and the plan fit together into one coherent picture you can hold and reason from.