Myth — "Coverage Closure Means Bug-Free"

No — coverage closure means the modeled scenarios were exercised and your checks did not fire, which is necessary confidence, but it is not proof of bug-freedom, because coverage measures stimulus not correctness and only measures what the model captures. There are three reasons closure is not bug-free. First, coverage measures stimulus, not correctness: hitting a coverage bin means the scenario occurred, that your stimulus reached that condition, but it says nothing about whether the design behaved correctly there — only checking, assertions and a scoreboard, confirms correctness. So a design could hit 100% coverage while computing wrong answers throughout, if the checking is weak, and the coverage report would read closed. Second, coverage measures only the scenarios the model defines: a scenario no covergroup captures is invisible to coverage, so an incomplete coverage model can close while leaving its blind spots completely untested — closure is only as complete as the model. Third, exclusions can hide reachable holes: a reachable bin excluded without honest justification, to hit the number, is an untested scenario behind a green report. So bugs hide in exactly the three places closure does not look: covered-but-unchecked behavior, scenarios the model never captured, and unjustified exclusions. What closure does mean is real and valuable — the verification space you defined was explored, with holes justified — which is strong confidence and a necessary milestone, but it is one input to sign-off, not the whole, and certainly not a guarantee of correctness. The understanding to convey is that closure proves the modeled scenarios were exercised, not that the design is correct or that the model was complete, so it is necessary confidence rather than proof of bug-freedom.

Because a covergroup samples and records that a condition occurred — that your stimulus reached a scenario — which is an observation about what was exercised, not a judgment about whether the design responded correctly, which is a different question that only checking answers. Coverage is instrumentation on the stimulus side: a coverpoint defines a condition, and when that condition is hit during simulation, the bin is marked, so the coverage database accumulates which scenarios were reached. That tells you completeness of exercise — did the stimulus get to this case — but it has no notion of right or wrong, because it is not comparing the design's output to an expected value; it is just noting that the case occurred. Correctness is the separate question of whether, given that the scenario occurred, the design produced the right result, and that is what checking does: assertions check local protocol rules continuously, and a scoreboard, usually with a reference model, compares observed outputs against expected end-to-end. So coverage and checking are complementary and answer different questions — coverage answers did we exercise this, checking answers did it behave correctly — and a scenario is only verified when both are true: it was covered and its result was checked. This is why coverage cannot stand alone: 100% coverage with no checking means every scenario ran and none was confirmed, which is exercise without verification. The right mental model is coverage as a map of where you have been and checking as the confirmation that the design did the right thing where you went. The understanding to convey is that coverage records occurrence not correctness because it instruments stimulus rather than comparing outputs, and that correctness requires the separate checking layer, which is why coverage closure alone does not prove the design correct.

Bugs hide in three places that 100% coverage does not address: behavior that was covered but not checked, scenarios the coverage model never captured, and reachable holes excluded from the model without justification. The first is unchecked behavior: coverage records that a scenario was exercised, but if there was no check on the design's response in that scenario, a wrong response passes silently — so even a fully covered scenario can contain a bug if the checking there was weak or absent, because coverage confirms occurrence, not correctness. The second is the coverage model's blind spots: coverage can only measure scenarios the model defines, so any behavior, corner, or interaction that no covergroup captures is invisible — the coverage reads 100% of what was modeled while the unmodeled scenario, which could harbor a bug, was never even measured, let alone exercised on purpose. An incomplete model gives a falsely complete-looking number. The third is unjustified exclusions: a reachable bin removed with ignore_bins or a waiver to make the report close, when the scenario it represents is actually reachable, is an untested scenario hidden behind the green number — the gap was buried rather than closed. So 100% coverage narrows where bugs can be — the modeled, exercised, checked scenarios are confirmed — but it does not eliminate them, because the unchecked, the unmodeled, and the wrongly-excluded remain. This is why sign-off requires more than coverage: strong checking so covered scenarios are confirmed, a reviewed model so the blind spots are minimized, and honest exclusions so nothing reachable is hidden. The understanding to convey is the three hiding places — covered-but-unchecked, unmodeled, and unjustified-exclusions — which is precisely what coverage closure does not cover and why it is not bug-free.

Sign-off is based on a convergence of evidence, not a single number: functional coverage closed with holes justified, the checks all clean, the regression green and stable across seeds, the bug-discovery rate flattened over time, and the reviews complete. No one criterion suffices, and coverage closure is one input among several. Coverage closed with weak checking means scenarios ran unconfirmed; a flat bug rate at low coverage means large parts were never exercised; a clean run on one seed is not stable. So sign-off looks for the criteria agreeing. Coverage must be closed with the unhit bins triaged as genuinely unreachable and excluded, not ignored — and the model reviewed for completeness, since closure only assures the modeled space. The checks must be clean: assertions passing, lint and clock-domain-crossing clean, so the covered scenarios are confirmed correct, not just exercised. The regression must be green and stable run after run across many seeds, no unexplained flakes, since a flaky test is an unsolved bug. The bug-discovery rate, tracked over the project, must have flattened to near zero, which is the strongest empirical signal the design has stabilized — coverage at 100% with a bug found daily is not done. And the reviews must be complete so a second set of eyes confirmed the plan was executed. The senior act is the willingness to withhold sign-off when these do not converge, even under schedule pressure. So coverage closure is necessary but combined with clean checks, a stable regression, a flat bug rate, and reviews — the convergence is the basis, with coverage one part. The understanding to convey is the multi-criteria convergence and that coverage is one input not the decision, which is the correct, calibrated view of sign-off that the closure-equals-done myth misses.

I would say that 100% coverage means every modeled scenario was exercised, which is a real milestone, but verified additionally requires that the design was confirmed correct in those scenarios by checking, that the coverage model was complete enough to not have major blind spots, and that the exclusions were honestly justified — so I would ask about the checking, the model completeness, and the exclusions before agreeing the block is verified. I would frame it constructively: hitting 100% coverage is genuinely good and necessary, so I am not dismissing it, but it measures stimulus reach, not correctness, so the first question is what confirmed the design behaved correctly in all those covered scenarios — are there assertions covering the protocol, a scoreboard with a reference model checking end-to-end, and were they actually exercised across the covered space — because 100% coverage with weak checking is fully exercised and barely confirmed. The second question is whether the coverage model is complete: does it map to the verification plan's features, or are there scenarios and interactions it never captured, since closure only assures the modeled space and an incomplete model closes while leaving blind spots. The third is the exclusions: were the unhit bins excluded because they are genuinely unreachable and documented as such, or were reachable holes waived to make the number close. If checking is strong, the model is reviewed-complete, and the exclusions are justified, then 100% coverage is a strong part of the verification story; if any of those is weak, the coverage number is overstating the assurance. And I would add that even then, verified for sign-off means the convergence — coverage plus clean checks plus a stable regression plus a flat bug rate plus reviews — not coverage alone. The understanding to convey is the constructive correction that asks about checking, model completeness, and exclusions, reframing 100% coverage as necessary-but-not-sufficient, which is how you correct the overclaim without dismissing the real value of closure.