What does coverage completeness actually mean at sign-off? Every verification plan names coverage criteria, but few define them precisely enough to guide a tapeout decision. A common version reads: "98% line coverage, 95% branch coverage, 90% functional coverage." The figures get recorded, presented during review, and rarely questioned until a silicon escape exposes how little those figures said about the remaining risk.
The issue is not only whether the thresholds are appropriate. Applying one percentage to a mixed coverage database hides important detail. A 95% aggregate functional coverage result can sit beside 0% coverage for interrupt controller reset sequencing, precisely the kind of omission that can become a post-silicon bug. Useful tapeout criteria must separate coverage by risk-relevant categories rather than grouping it by whatever is simplest to count.
Why Line and Branch Coverage Still Fall Short
Line and branch coverage measure structure. They show whether the testbench reached a particular line of RTL or exercised a particular branch. That makes them valuable for RTL quality: untouched paths are either dead code that should be deleted or live behavior that the testbench has not exercised.
Structural metrics say nothing about whether the exercised behavior is functionally correct. An interrupt controller can reach 100% branch coverage while never handling two simultaneous interrupts at the same priority during a context switch. That case may exist in a functional coverpoint. It may also be absent entirely if the testbench author did not consider it while building the coverage model.
Branch coverage is easy to inflate. A 200-state FSM can report 95% branch coverage while 15 transitions remain untouched. Those transitions may define correct error handling. The percentage looks acceptable, but the gap still matters.
Criteria limited to line and branch thresholds are not incorrect. They are incomplete: a baseline, not a complete sign-off standard.
Functional Coverage Needs Design Expertise
Functional coverage shows whether a verification plan reflects the design it is meant to check. Its value depends on the person who defined it. So the important question behind a 90% functional coverage result is this: who created the covergroups, and what did they understand about the design at that point?
Covergroups created early represent the team's understanding when testbench work started. RTL changes, newly found corner cases, bug fixes, and microarchitecture changes made under schedule pressure can leave the model out of date. Points added for regression bugs remain useful evidence. Points tied to design intent that was later changed may instead measure behavior that no longer exists.
For each block, the functional coverage review should distinguish three sources. Which covergroups came from the specification before RTL development? Which were added after simulation exposed bugs? Which points were excluded or waived, and for what reason? Combining all three into one percentage does not provide the evidence needed for a sound go or no-go decision.
Assertion Pass Rate Needs a Clearer Definition
SVA assertions are standard in serious verification environments, yet tapeout criteria often omit a requirement for their pass rate. That leaves several silent failures unexamined: assertions disabled after false positives, assertions never triggered because their conditions were not simulated, and assertions that passed vacuously because their antecedents were never satisfied.
Track assertion vacuity explicitly: how many assertions had an antecedent, the condition that activates the check, that never became true during simulation. A vacuous pass is not evidence of passing behavior. It means the testbench never activated the check, so the intended behavior remains uncovered.
A minimal assertion criterion is straightforward: every critical assertion, as labeled in the assertion database, needs a non-zero antecedent activation count in the regression database. Activated assertions must have a 100% pass rate, with a documented explanation for every waiver. This separates assertions that passed from assertions that never ran.
Minimum Tapeout Coverage Checklist
Drawing on verification plans and tapeout reviews with BigEndian early-access teams, this checklist organizes the coverage dimensions most connected to post-silicon risk. These are not proprietary BigEndian requirements. They are established practices that teams apply unevenly.
Block-level functional coverage. Report each block-level covergroup independently. Aggregated results can conceal under-covered blocks. Require at least 95% per block, with a documented waiver for every uncovered bin that has been reviewed and accepted.
Cross-block interaction coverage. Use covergroups to capture joint state across module boundaries, especially for shared bus masters, interrupt controllers, DMA controllers, and power domain interfaces. These are often omitted because they require coordinated agents, yet they expose some of the most serious post-silicon bugs.
Reset and power sequencing coverage. Define coverpoints for reset assertion and deassertion under varied load conditions, including an active transaction, a pending interrupt, an ongoing DMA transfer, and a power domain transition. Review this category separately because aggregate functional coverage often misses these common escape paths.
Error injection and recovery coverage. Track error detection, reporting, and recovery paths with dedicated coverpoints. Review them separately because directed error tests are often created once and not expanded as the error-handling logic changes.
Assertion activation coverage. Track assertions per block, those with non-zero antecedent activation, and the pass rate for activated assertions. Tapeout requires that no assertion pass only vacuously.
Waiver Review Is Part of Criteria
Reaching 95% functional coverage by waiving the difficult 5% does not certify 95% coverage. It certifies 80% coverage, plus a record of gaps the team chose not to close.
Waivers can be valid. Some bins are unreachable under legal operating conditions, and excluding them is the right choice. For example, reset behavior on a write port while the entire memory subsystem is in retention mode may be specified as don't-care, making a waiver legitimate.
A valid waiver needs a risk statement: this bin represents condition X, functional failure would require Y, and Y cannot occur under the specified operating conditions because Z. "Hard to reach with current testbench" and "no time remaining in schedule" describe schedule constraints, not risk. Record those bins as known residual risk rather than waived coverage.
At tapeout review, ask more than "what is the coverage number." Ask what remains uncovered, why it remains uncovered, and what could happen if the condition occurs in silicon. Criteria that answer those questions give the sign-off team evidence to assess. A context-free percentage only supplies a number to approve.