Verification Signoff and Metrics
Coverage Closure already made the core point for one metric: a coverage percentage alone is a decision input, never a decision. This page extends that to the full set of signals a real project actually combines before tapeout — and the honest reason no single number, however high, is ever sufficient by itself.
Signoff is a sequence of independent checks, not one number
Every technique across this curriculum checks something the others structurally cannot: functional coverage confirms the spec's scenarios were exercised; code coverage confirms the RTL itself ran; formal proves specific properties exhaustively; CDC/RDC confirm clock and reset boundaries are safe; linting and GLS catch structural and synthesis-specific issues; timing confirms the design meets its constraints. Signoff is the conjunction of all of these passing, independently — not an average, and not a single blended score. A design with 99% functional coverage and one unresolved CDC violation is not "99% ready" — it has a specific, unresolved, potentially catastrophic problem that a high coverage number doesn't offset in the slightest. Missing any one independent check risks a real silicon failure regardless of how strong every other number looks.
The metrics that actually get combined
| Metric | What it confirms | What it's blind to |
|---|---|---|
| Functional coverage | Spec-defined scenarios were exercised | Whether the RTL itself has structural issues |
| Code coverage | The RTL's structure actually ran | Whether the result computed was correct |
| Formal properties proven | Specific properties hold for every input, exhaustively | Only for the properties someone wrote — silent on everything else |
| CDC/RDC clean | Clock and reset boundaries are structurally and protocol-safe | Ordinary functional or timing bugs entirely outside crossings |
| Lint / GLS clean | No structural code issues; post-synthesis behavior matches RTL intent | Whether the design itself, correctly synthesized, is functionally correct |
| Regression pass rate | Nothing previously working has broken | Anything the test suite doesn't already exercise |
| Open high-severity bug count | Known, tracked issues remaining | Bugs nobody has found yet |
| Planned tests written | Every test the verification plan committed to actually exists and runs | Whether an existing test actually exercises the scenario well, or checks the result correctly |
No row in this table can stand in for any other — each one is a distinct, independent lens, exactly the "sequence of checks that must each pass" framing above. The last row is worth calling out specifically: it's a different kind of gap than a coverage hole. A coverage percentage can look complete while a test the plan explicitly promised — named in a row, tracked as a requirement — was never actually written at all; "planned vs. written" catches a plan that's aspirational on paper but incomplete in the test suite itself.
Why this many independent gates, rather than trusting the strongest one or two? Industry-wide first-silicon success rates — the fraction of chips that come back from the fab working correctly with no respin needed — are reported at well under half in recent surveys, a sobering real-world number given how much of this curriculum exists specifically to push that rate up. No single metric in the table above, however strong, has ever been the thing standing between a design and that statistic; it's always the conjunction.
The bug-discovery curve
One further signal worth reading directly, not just tallying: the rate at which regression finds new bugs over time.
A curve that's still climbing, or holding steady, says the test suite is still finding real problems at a meaningful rate — a strong signal it's premature to sign off, regardless of what the coverage percentage says. A curve that's genuinely flattened — not just one quiet week, but a sustained trend — is one of the strongest real indicators that the design has stabilized, precisely because it's measuring something coverage can't: not "did we look," but "are we still finding things when we look."
Where coverage holes and formal meet, one more time
A genuinely useful closing technique, worth calling out directly: when functional coverage flattens below 100% and the remaining holes resist every constraint refinement Coverage Closure described, formal verification can be pointed specifically at those remaining bins — proving whether they're actually reachable at all. If formal proves a stubborn hole is structurally unreachable, that's the justified waiver Coverage Closure required, backed by a proof rather than an assumption — and the signal to stop spending further testbench effort chasing something that was never closable by testing in the first place.
What's next
Every process-level piece — planning, execution, and the signoff decision itself — is now covered. Section F closes this topic: the verification IP ecosystem, and a capstone applying everything from this curriculum to the FIFO and PWM DUTs already built elsewhere on this site.