In a DDR5 controller review, a six-page testplan listed forty-seven scenarios, yet its closure statement was only "all regression tests passing, coverage complete." Two protocol scenarios remained untested because no one had defined a numerical meaning for complete or assigned sign-off ownership.
Start With the Closure Gap
A verification testplan is an agreement between design and verification. It states what must be demonstrated, which coverage targets define completion, and who approves the evidence. Without that agreement, closure decisions move to tape-out review, when changing scope is expensive.
A testplan is not a catalog of tests already written. That catalog records the past. The plan must describe the required verification work, including scenarios the team has not implemented yet.
It is not a design specification either. The design spec defines intended RTL behavior. The testplan defines how the team will demonstrate that behavior. We are not saying the design spec should be duplicated. We are saying every relevant requirement needs a deliberate bridge into verification.
Build Traceability Into the Model
Every design requirement should map to at least one verification scenario, and every scenario should trace back to a requirement. Teams often create that relationship during project kickoff and stop maintaining it. Later, new requirements arrive without coverage groups, while speculative groups appear to chase uncovered bins.
Keep the mapping lightweight. Add a design spec reference to each scenario or coverage group, then maintain a corresponding review sheet that records the groups covering each requirement. At sign-off, the team can filter the mapping instead of searching commit history.
This view exposes three different conditions: a requirement with no coverage, a coverage group with no requirement, and a requirement whose coverage was removed or changed without a design review. The second condition may identify redundant work, while the first is a direct verification gap.
Specify Coverage Before Simulation
Write the coverage model before regression begins. Define whether functional, code, toggle, or combined coverage is in scope. Name the coverage groups, define their bins, set hit-count expectations, and document exclusions. Store the resulting evidence in the format the flow uses, such as UCDb or UCIS, whether the simulator is Xcelium, VCS, or QuestaSim.
Name functional coverage groups for the behavior they represent. cp_link_error_recovery tells an engineer what is missing. cp_state_bits only identifies an observed signal. When a group sits at 0 percent, behavior-based naming shortens diagnosis.
Bin granularity requires engineering judgment. A single bin covering a 200-value range can hide important corners. Excessively fine bins can create unreachable combinations. For each bin, ask which failure mode would escape if it were missed. If the answer is unclear, revise the bin.
Cross-coverage deserves the same specificity. Separate groups for conditions A and B can both reach 100 percent while the A and B interaction remains untested. Protocol timing, AXI ordering, and state-machine transitions often depend on that interaction, so the cross must be explicit.
Make Done Measurable and Owned
Define closure numbers before verification starts. "All tests passing" is a prerequisite for analysis, not a completion rule. "Coverage complete" is equally empty without a threshold. At 87 percent during tape-out review, a team cannot make a consistent decision if no target was agreed in advance.
A usable rule might require 95 percent functional coverage across every planned group, documented exclusions approved by the design spec owner, line coverage above 90 percent, branch coverage above 85 percent, and zero unresolved failures in the final full regression.
Those percentages are not universal. A block may require a different risk-based threshold. The essential point is prior agreement. A team that sets 90 percent functional coverage as its target has a defined discussion at 88 percent. A team with no target is negotiating from the result backward.
Assign one named owner to each scenario. That engineer confirms the test exists, the intended coverage groups are exercised, and the scenario is ready for review. Ownership is a coordination mechanism, not a punishment mechanism.
For a small verification group, explicit ownership prevents duplicate constrained-random tests and prevents an unclaimed scenario from remaining at zero coverage near tape-out. ChipAgents can support this review loop with its Test Writer, Coverage Tracker, and Failure Explainer agents, but the owner and approval authority still belong in the testplan.
Use a Reviewable Testplan Structure
A practical template contains six sections:
Block description: module path, interfaces, integration context, and a short scope statement.
Verification goals: required properties, excluded failure modes, interaction scenarios, and references to design requirements.
Coverage model: groups, bins, crosses, hit counts, thresholds, and the exclusion approval policy.
Scenario list: scenario name, purpose, targeted groups, owner, and status. This is the working section and should change with the project.
Done criteria: the numerical closure statement repeated in one unambiguous location.
Sign-off process: reviewer, coverage report requirements, and scheduled review date. Without a reviewer and a date, sign-off is an intention rather than a process.
Review the Exceptions, Not Just the Green Dashboard
Writing the testplan after verification produces a polished record of existing tests and can omit scenarios that were never planned. Coverage groups without scenario notes create the opposite problem: engineers must reverse-engineer intent from the formal specification when a group is at 0 percent.
"Per project sign-off checklist" is not a closure definition if the checklist supplies no number. Put the threshold in the testplan. Likewise, a passing dashboard does not prove that an ambiguous requirement or an ECO was handled correctly.
A detailed plan cannot guarantee closure. Design ambiguity, late RTL changes, and removed coverage can still create gaps. The value of the plan is earlier visibility: the team can distinguish an untested requirement from an unnecessary bin while there is still time to respond. In review, that distinction is more useful than a single aggregate percentage.