It is Thursday afternoon, and the DMA's tape-out readiness review is on Monday. The dashboard looks fine: every nightly run passes, all 17 plan items are hit in the merged result, and there is one waiver. Your manager would like a short "yes". You know three more things. The waiver is DMA-142, and the false-pass playbook showed a planted bug hiding under it. The coverage build crashes in 8 of 20 runs. The block bench has no protocol assertions enabled in regression. How do you run the review so that the decision is made on what is true, and how do you say "not ready" if that is the answer?
No block is ever perfectly verified. Sign-off is not the moment every number reaches 100%; it is the moment the people accountable agree that the remaining risk is known, small and accepted by name. Your job as the DV lead is to make that risk visible, honest and owned: what is verified, what is not, what each gap could cost, and what it would take to close it. A pilot's go/no-go check is the right picture. Nobody waits for a perfect aircraft; they confirm that every known issue is either fixed, within limits, or deliberately accepted by the captain, and they write that down.
Metrics and Sign-off covers the inputs: what each metric shows, how it misleads, and the checklist. This lesson is about running the review itself.
Send it two working days ahead, so people come with questions rather than discovering the gaps in the room. Lead with the recommendation and the gaps; the green numbers go below. For the DMA, from the course's real sheet, the top of the page would read:
DMA block: tape-out readiness, recommendation NOT READY (3 items, earliest close: 6 working days)
1. Waiver DMA-142 (5 SB_MISMATCH, dma_waiver_test). Root cause: the predictor ignores
the busy-write rule (war story 9). A planted bug at word 6 passes under this waiver.
Action: fix the predictor, delete the waiver, rerun the mutation build. Owner: data-path owner
2. Coverage build crashes 8 of 20 runs; merged coverage uses complete runs only.
Action: tool ticket; rerun until 20 complete. Owner: regression owner
3. No protocol assertions in the block regression.
Action: enable the APB checker and the DMA rule checker, nightly. Owner: register owner
Green: 61/61 nightly runs pass; 17/17 plan items hit (merged, passing runs);
planted word-6 bug caught by 26 of 30 regular runs (the 4 misses cannot reach word 6).
Not run on this project: GLS, power-aware simulation (out of scope; required on a real chip).Every gap has an action, an owner and a date. A gap without those is a complaint, not a plan.
Every number has a denominator and a source. "17/17, merged, passing runs" can be checked; "100% coverage" invites the question you would rather answer in advance.
What was not run is listed, with the reason. Leaving GLS off the page does not make the question go away; it makes it come up in the meeting, from someone else.
The right people: the design lead, the architect or system owner, the project manager, and DV. Without someone who can accept risk, the meeting can only produce a recommendation.
Walk the gaps, not the slides. For each: what could go wrong in silicon if it is real, how likely, what closing it costs. The DMA-142 item is easy to explain: "a real data-path bug in the same word range would pass our regression today; we showed it with a planted bug".
Close each item with a decision and write it down in the room: fixed before tape-out, accepted with a named owner, or descoped with a software workaround.
A waiver is a statement that a failure is understood and harmless. The DMA-142 story is why each one needs its scope (one ID, one component, one pattern), its count (fail if it changes), its owner and expiry, and a mutation run on the waived tests: a waiver over a whole message ID blinds that checker to any bug that produces the same message. Open bugs need their severity, whether the fix is in the build being signed off, and a guard test that fails if the bug returns. The other verification streams each get one status line: formal proofs (proven, bounded to a justified depth, or open), gate-level simulation (link: Gate-Level Simulation) and power-aware simulation (Power-Aware Simulation).
Saying no in a sign-off review is part of the job, and the way you say it decides whether it helps. Three rules make it land. Be specific: name the items, not a feeling ("I'm not comfortable" invites "why not?"; "two items, here they are" invites "what do you need?"). Bring the path: actions, owners and the earliest date you can stand behind. Offer the options the decision-makers actually have: fix and slip, ship with the risk accepted in writing by a named person, or reduce scope (a feature disabled by a register bit or fuse, with software told). Then let them decide. Your job is to make the risk impossible to misunderstand, not to own the business decision.
A spoken version for the DMA: "My recommendation is not ready, by about six working days. Our regression cannot currently catch a data bug in the words covered by the DMA-142 waiver; we showed that with a planted bug. Fixing the predictor and removing the waiver closes it, and the data-path owner estimates four days plus a rerun. If the date cannot move, I need someone from the design side to accept that risk in writing, and I'd add a silicon bring-up test that writes KEY while busy."
The most common sign-off failure is not a wrong decision; it is a conditional one that evaporates. "Ready, provided the waiver is closed before final tape-out" is recorded in the minutes, the meeting ends, and nobody owns the condition. Three weeks later the database is frozen with the waiver still in place, and the condition is discovered during an escape review. A condition is only real if it has an owner, a date, a ticket that blocks the next milestone, and a check in the next review's pre-read. Treat it exactly like an open bug.
The source and the conditions: merged across which tests and seeds, from passing runs only, on which build, and from which tool (here, the plan-item tally, because Verilator's covergroup percentages are not meaningful). If coverage from failing or crashed runs was included, the number may count scenarios that were never checked.
Not without review. An unchanged count does not show the waiver is harmless; DMA-142's count also stayed at 5 while a planted bug hid under it. Find the ticket, confirm the root cause still applies, run the waived tests with a mutation build, and either fix the cause and delete the waiver or re-approve it with an owner and an expiry date.
As a decision with its reason and owner: GLS not run, accepted because formal equivalence between RTL and netlist passed (with the report referenced), by the named design lead. Note what equivalence does not cover (timing-related reset and X behaviour, for example) and whether any GLS smoke test is still planned. The point is not to win the argument but to make the choice explicit.
Next: sign-off assumes the specification stood still. Spec Change and Bug Escape handles what happens when it does not, and when something gets through anyway.