UVM
UVM Coverage Checklist
The condensed sign-off list for a functional coverage model — covergroups that map to the verification plan, meaningful bins and crosses that do not explode, a correct sampling strategy, and the closure discipline that turns running tests into knowing what was verified.
UVM Design Review Checklist · Module 31 · Page 31.3
The architecture and reuse checklists confirmed the environment is built and composable. This one confirms it measures the right things: a functional coverage model that maps to the verification plan, with meaningful bins and crosses that do not explode, a sampling strategy that captures what happened, and the closure discipline that turns "we ran a lot of tests" into "we exercised what matters." Coverage is how verification becomes measurable — but a bad coverage model is worse than none, because a meaningless 100% gives false confidence. This checklist is the pass that catches a model that explodes, never closes, or measures the wrong thing.
1. Why a Coverage Checklist: A Bad Model Gives False Confidence
You have learned why functional coverage matters — it is what makes "verified" measurable and turns an open-ended constrained-random run into a closable effort. A coverage checklist ensures the model actually measures meaningful things, because a coverage number is only as good as the model behind it. A model with full crosses of unbinned wide values explodes into millions of meaningless bins and never closes; a model that samples at the wrong moment records garbage; a model that covers the easy cases and misses the corners reports a high number while the bugs hide in the uncovered scenarios. The checklist catches the meaningless-coverage mistakes — the explosion, the wrong sampling, the unjustified exclusion — before a green coverage report signs off a design that was never really exercised.
2. Coverage Model Design
The first category is whether the model measures meaningful things without exploding — the items that keep coverage tractable and tied to intent.
- Covergroups map to the verification plan's features. Each covergroup corresponds to a feature area from the plan, so coverage measures verification intent and a hole points at a real untested scenario — not an arbitrary set of bins.
- Coverpoints have meaningful bins, not every value. A wide value (address, length) is binned into meaningful categories — boundaries, aligned/unaligned, legal/illegal ranges, min/max/typical — not one bin per value; unbinned wide coverpoints are the first source of explosion.
- Crosses cover only real combinations. Cross only the dimensions whose combination is a genuine scenario; a full Cartesian cross of high-cardinality coverpoints produces millions of meaningless bins that never close.
ignore_binsandillegal_binsprune the model. Combinations that cannot happen areignored (removing them from the denominator) and combinations that must never happen areillegal(flagging them if hit) — so the cross covers the interesting intersections, not the full grid.- The model is structured to mirror the feature list. One covergroup per feature area keeps coverage readable and makes a hole map directly to an untested feature.
3. Sampling Strategy
The second category is when and where coverage is sampled — the items that keep the recorded coverage truthful.
- Coverage is sampled at the moment the coverpoint's condition holds. Sampling on the wrong event records the wrong value; the sample event must coincide with when the measured condition is actually valid (e.g., on transaction completion, not mid-transfer).
- Sampling happens in the monitor/subscriber, off observed transactions. Coverage rides the analysis path — a coverage subscriber connected to the monitor's analysis port — so it measures what actually happened on the bus, not what was intended.
- Explicit
sample()calls or@(event)triggers are deliberate. Whether the covergroup samples on a clocking event, awithevent, or an explicit call, the trigger is chosen so each sample captures one meaningful occurrence — no double-counting, no missed events. - Sampling does not depend on a path that a passive instance lacks. Coverage collection works whether the agent is active or passive, since coverage is wanted especially at SoC level where the agent observes.
4. Closure Discipline
The third category is the process that drives coverage to a meaningful close — the items that make the number mean something.
- Coverage is merged across all seeds and tests. The real coverage is the union over the whole regression, so every run's coverage is merged into one database; a single seed's coverage is not the picture.
- Holes are triaged into real, unreachable, or rare. Each unhit bin is classified: a real reachable hole is an untested scenario to drive, an unreachable bin is excluded (refining the model), and a rare-but-reachable hole needs targeted stimulus.
- Stimulus is driven at the real holes. Bias the constrained-random constraints toward the uncovered region, or write a directed test for a stubborn corner — closure is active, not waiting for random to wander into the hole.
- Every exclusion is justified as genuinely unreachable. An
ignore_binsor waiver is documented as truly unreachable, never used to hit a number — a reachable hole wrongly excluded is an untested scenario where a bug hides. - Closure is gated on the meaningful coverage, with holes justified. "Done" is the target hit with remaining holes triaged and justified — not a raw percentage that includes meaningless or unreachable bins.
5. Coverage vs Checking
The fourth category is the boundary between measuring and checking — the items that prevent coverage being mistaken for correctness.
- Coverage measures stimulus completeness, not correctness. A covergroup records that a scenario occurred; it does not say the DUT behaved correctly there — coverage is observation, not checking.
- Assertions and a scoreboard accompany coverage. Local protocol correctness comes from assertions, end-to-end correctness from the scoreboard; coverage without checking tells you that you stimulated a scenario but not whether it passed.
- A covered-but-unchecked scenario is not verified. Hitting a coverage bin with no check on the result means the scenario ran but its correctness was never confirmed — coverage and checking must both be present for a feature to count as verified.
- Coverage guides where to check, not whether checking is needed. Coverage shows which scenarios were exercised so checking can be confirmed there; it never substitutes for the check.
6. Common Misconceptions
7. Sign-off Insight
8. Interview Questions
You keep it tractable by covering what is meaningful rather than everything possible — meaningful bins instead of every value, crosses only of real combinations, and ignore and illegal bins to prune the impossible. The explosion comes from crosses and unbinned wide values: cross three coverpoints of a hundred bins each and you have a million cross bins, most of them meaningless, and the model never closes because most bins are unreachable or irrelevant. The discipline is, for each coverpoint, to define bins that correspond to meaningful categories — for an address, the boundaries, the aligned and unaligned cases, the legal and illegal ranges, not every address; for a length, the minimum, maximum, typical, and corner values. For crosses, cross only the dimensions whose combination is a real scenario, and use ignore_bins to remove combinations that cannot happen and illegal_bins to flag combinations that must never happen, so the cross covers the interesting intersections rather than the full grid. Structure the model to mirror the feature list, one covergroup per feature area, so coverage maps to verification intent and a hole points at a real untested scenario. The alternative — coverpoints on raw wide values and full crosses — produces a model with a huge number of bins, most meaningless, that never reaches closure and whose number gives no real information. The understanding to convey is that coverage is a model of intent, not an enumeration: meaningful bins, crosses of real combinations only, pruned with ignore and illegal bins, structured by feature — so the number means something and closure is achievable.
Because coverage measures whether you stimulated a scenario, not whether the DUT behaved correctly in it — so 100% coverage with no checking means every scenario ran and none of them was confirmed correct. Coverage is observation: a covergroup samples what happened and records that a condition occurred, telling you your stimulus reached that condition, but it says nothing about whether the design produced the right result there. You could hit every coverage bin while the DUT computes wrong answers throughout, and the coverage report would read 100% while the design is broken. That is why coverage must always be accompanied by checking: assertions for local protocol correctness, checked continuously, and a scoreboard for end-to-end functional correctness, comparing observed results against expected. Coverage and checking answer different questions — coverage answers did we exercise this scenario, checking answers did it behave correctly — and a feature is verified only when both are true for it: it was stimulated and its result was confirmed. A covered-but-unchecked scenario is not verified; it merely ran. The right reading of coverage is as a measure of completeness of stimulus that tells you where your checks were exercised, not as a measure of correctness. The understanding to convey is that coverage measures stimulus not correctness, that it needs assertions and a scoreboard alongside it, and that verified means stimulated-and-checked — which is why a high coverage number alone is not a sign-off and can give dangerous false confidence.
Coverage closure is an iterative loop: run the regression across many seeds, merge all the coverage into one database, analyze the merged result for holes, triage them, drive targeted stimulus at the real holes, and repeat until the meaningful coverage closes with remaining holes justified. The merge is essential because a single seed or test hits only some coverage; the real picture is the union across the whole regression, so you merge every run into one database. Then you analyze that merged database for holes — unhit bins — and triage them into three kinds: real reachable holes are scenarios that matter and must be hit, unreachable bins are excluded as ignore or illegal which refines the model rather than hiding a gap, and rare-but-reachable holes need targeted help. For the real reachable holes you drive stimulus, usually by biasing the constrained-random constraints toward the uncovered region, sometimes by adding seeds, and for a stubborn corner that random will not reach economically, by writing a directed test. Then you rerun, remerge, and check the holes closed and nothing regressed. The loop repeats until coverage reaches the target with the remaining holes justified as unreachable and the bug rate flat. The crucial discipline is that an excluded hole must be justified as genuinely unreachable, never excluded just to hit a number, because a reachable hole wrongly excluded is an untested scenario where a bug hides. The understanding to convey is the run-merge-analyze-drive-repeat loop with honest exclusion triage, which is how a campaign turns running tests into closing meaningful coverage.
Sampling timing matters because a covergroup records the value of its coverpoints at the instant it samples, so if you sample at the wrong moment you record the wrong value and the coverage is simply false. A coverpoint means a particular condition — say the burst length of a completed transaction, or the state when a transfer finishes — and that condition has a specific valid moment. If you sample before the value is settled, mid-transfer when signals are transitioning, or after the relevant state has already moved on, the sampled value does not reflect the condition the coverpoint is supposed to measure, and the coverage database fills with values that never really occurred or misses values that did. So the sample event must coincide with when the measured condition is actually valid — typically on transaction completion for transaction-level coverage, on the right clocking event for signal-level coverage. In UVM, coverage is usually collected in a subscriber or the monitor off observed transactions, sampling when the monitor has reconstructed a complete, valid transaction, so the sample reflects what actually happened on the bus. The trigger — an explicit sample call, a with event, or a clocking event — is chosen deliberately so each sample captures exactly one meaningful occurrence, with no double counting and no missed events. The consequence of getting it wrong is a coverage report that looks fine but measures garbage, which is worse than no coverage because it gives false confidence. The understanding to convey is that the sample must land at the moment the coverpoint's condition is valid, that coverage is sampled off observed transactions for truthfulness, and that wrong sampling produces false coverage.
It is legitimate to exclude a coverage hole only when the bin is genuinely unreachable — a combination that cannot physically occur given the design and its legal configurations — and it is dangerous when the bin is actually reachable and is excluded just to hit a coverage number, because that hides an untested scenario where a bug can live. Coverage models legitimately contain bins that can never be hit: an illegal protocol combination, a configuration the design does not support, a cross of mutually exclusive conditions. Removing those with ignore_bins is correct — it refines the model so the denominator reflects what is actually reachable, and the coverage number becomes meaningful rather than capped below 100% by impossible bins. The danger is the opposite: a bin that is reachable, representing a real scenario, but hard to hit, and someone excludes it to make the report read closed. That is not refining the model; it is hiding a gap. The scenario the bin represents was never exercised, so if there is a bug in it, verification never had a chance to find it, and the green coverage report gives false confidence that it was covered. The discipline is therefore that every exclusion must be justified as genuinely unreachable, documented with the reason, and ideally reviewed — so the distinction between refining and hiding is explicit and auditable. A reviewer should treat the exclusion list as a place where untested scenarios can be quietly buried and check each one. The understanding to convey is unreachable-exclusion-is-refinement versus reachable-exclusion-is-hiding-a-gap, and that justified, documented exclusions are the line between the two.
9. Summary
The UVM coverage checklist confirms the environment measures the right things — that the coverage number means something — rather than reporting a meaningless or false percentage. It is organized into four categories. Model design: covergroups map to the verification plan, meaningful bins (not every value), crosses of real combinations only, and ignore/illegal bins to prune — keeping the model tractable and tied to intent. Sampling strategy: sample at the moment the coverpoint's condition is valid, off observed transactions, with deliberate triggers — so the recorded coverage is truthful. Closure discipline: merge across seeds, triage holes into real-versus-unreachable, drive stimulus at the real ones, and justify every exclusion as genuinely unreachable. Coverage versus checking: coverage measures stimulus not correctness, so assertions and a scoreboard must accompany it — a covered-but-unchecked scenario is not verified.
The disciplines: run it at model design and again at closure (a meaningful model designed up front and a number that means something at the end); check the highest-impact items explicitly (pruned crosses so the model closes, and justified exclusions so no scenario is buried); and never let coverage stand alone — it is meaningful only alongside the checks that confirm correctness where it says scenarios were exercised. A bad coverage model is worse than none because a meaningless 100% gives false confidence, which is exactly what the checklist exists to prevent.
10. What Comes Next
You can now sign off a coverage model; next, signing off the register layer:
Next — RAL Checklist: coverage measures what was exercised; the RAL checklist confirms the register layer is integrated correctly — the register model and its access policies, the adapter's round-trip, the predictor connected for explicit prediction, and frontdoor-versus-backdoor used for the right purpose — so register verification self-checks against the DUT rather than a stale mirror.