Coverage Issues

UVM Debugging · Module 27 · Page 27.8

The Engineering Problem

A coverage hole won't close — you throw more stimulus at it, more random seeds, directed tests, and it stays at zero. Or the opposite: coverage closes suspiciously fast — 100% on a key covergroup after barely any testing — and you sign off, confident. Both are coverage issues (from 27.1's family: a coverage hole that won't close, or suspiciously complete coverage), and they're two directions of the same deeper problem: coverage is a measurement, and a broken coverage model lies — in either direction. It can under-report: a hole that won't close not because stimulus is missing but because the covergroup isn't sampled, is sampled at the wrong time, has a bin that can never be hit, or covers the wrong variable — so you chase stimulus that can never close it. Or it can over-report: suspiciously complete coverage that measures the testbench's own stimulus rather than the design's behavior, or uses bins so coarse anything hits them — so 100% means nothing. The over-report is the more dangerous — like the silent scoreboard (27.4) and the zero-time green (27.6), it produces false confidence: you believe you verified the design when you covered your own stimulus. The trap with the under-report is chasing stimulus for a hole that's a sampling or model bug, not a stimulus gap; the trap with the over-report is trusting a number that measures the wrong thing. The problem this chapter solves is coverage issues: applying the methodology to functional coverage — reading the symptom (hole won't close vs suspiciously complete), observing the coverage report and the sampling points, and confirming and fixing each so coverage measures what was actually verified.

Coverage issues are failures of the coverage model as a measurement — under-reporting (a hole that won't close) or over-reporting (suspiciously complete) — that make coverage not measure what was actually verified. The under-report causes: the covergroup is never sampled (not constructed, or .sample() never called — 0% across the board, a sampling bug, not a stimulus gap); sampling at the wrong time (.sample() at the wrong instant — before the value is valid, after it changed, wrong edge — so it records stale or wrong values); a bin that can never be hit (defined for a value the design can't produce — an unhittable hole no stimulus can close); or coverage on the wrong variable (a coverpoint sampling a variable that isn't the design state you meant — so the hole won't close because you're covering the wrong thing). The over-report causes: measuring the testbench, not the design (the covergroup samples the value you drove rather than the DUT's behavior — so coverage measures what you stimulated, not what the design did, and closes trivially); or bins too coarse (bins so broad that any value hits them — trivially 100%, hiding the real holes). The crucial asymmetry: the under-report wastes effort (chasing stimulus for an unhittable/unsampled hole), but the over-report is dangerous — it produces false confidence (100% coverage that verified nothing). The methodology applied: the symptom is a hole that won't close or suspiciously complete coverage; localize to the coverage model; observe the coverage report (which bins are 0 or 100) and the sampling points (is it sampled? when? on what variable?); confirm whether it's a sampling/model bug (under) or measuring the wrong thing (over); and fix (construct and sample at the right time, remove unhittable bins, sample the design variable, refine coarse bins). This chapter is coverage issues: the two directions, the sampling points, the observation, and the fixes.

Why does a coverage hole refuse to close despite stimulus, or coverage close suspiciously fast — and how are these two directions of a broken coverage model (under-reporting from a sampling or model bug, over-reporting from measuring the testbench or coarse bins) found by observing the coverage report and the sampling points, with the over-report the dangerous false-confidence case?

Motivation — why coverage lies in two directions

Coverage is a measurement, and a measurement can be wrong by reading too low or too high — each with a different trap. The reasons:

• The under-report sends you chasing stimulus that can't help. A hole that won't close looks like a stimulus gap ("I haven't hit this case"), so you write more tests and try more seeds — but if the covergroup isn't sampled, the bin is unhittable, or you're covering the wrong variable, no stimulus can close it. You burn effort on a measurement bug.
• The over-report is false confidence — the worst failure. Suspiciously complete coverage looks like thorough verification, so you sign off — but if the coverage measures the testbench or uses coarse bins, 100% means nothing. You've verified less than you think and shipped on a false number.
• Sampling is invisible in the coverage number. The coverage report shows percentages, but not whether the covergroup was sampled, when, or on what variable — so a sampling bug (the deepest cause of both directions) is invisible unless you look at the sampling points, not just the number.
• "Measuring the testbench" closes trivially and means nothing. A covergroup that samples the value you drove hits all its bins as soon as constrained-random generates all values — which is fast and easy — so it closes quickly and feels like progress, while measuring the design's actual behavior (which it doesn't) would show the real holes.
• Both directions corrupt the sign-off decision. Coverage drives sign-off ("are we done?"). An under-report says "not done" when you are (wasting effort); an over-report says "done" when you're not (shipping bugs). A wrong measurement makes the whole closure decision wrong.

The motivation, in one line: coverage is a measurement that drives sign-off, and it lies in two directions — under-reporting (a hole that won't close from a sampling/model bug, sending you chasing stimulus that can't help) or over-reporting (suspiciously complete coverage that measures the testbench or coarse bins, giving false confidence) — and both are invisible in the percentage unless you observe the sampling points, so you must check what is sampled, when, and on what variable, not just the number.

Mental Model

Hold coverage as a fitness tracker that must measure your real activity — wrong if it's off, mis-timed, set an impossible goal, or counting the wrong motion:

Imagine you rely on a fitness tracker to tell you how much you've actually exercised. The number it shows drives your decisions — whether you've done enough, whether to keep going. For that number to mean anything, the tracker has to actually measure your real activity, and there are several ways it fails to. First, it might not be measuring at all — you forgot to wear it, or never started the session — so no matter how hard you exercise, it reads zero. You could run a marathon and the tracker says you did nothing. Second, it might measure at the wrong time — only sampling while you're sitting still — so it badly under-counts real effort. Third, it might have a goal you can never reach — a target for steps in a twenty-fifth hour of the day — and that goal will simply never complete, no matter what you do, because it's impossible by construction. Those three make the tracker read too low: you've done the work, but the number doesn't reflect it, and adding more exercise won't fix a tracker that isn't measuring you. But there's a fourth failure that's worse, because it reads too high. Suppose the tracker is counting the wrong motion entirely — it's picking up the car's movement while you sit in traffic, or the washing machine's vibration, instead of your steps. Now it happily reports you hit your goal, while you did no exercise at all. That's the dangerous one: a low reading makes you do unnecessary extra work, but a high reading from measuring the wrong thing makes you believe you're fit when you're not. The number looks great and means nothing. The tracker only tells you something true if it's actually on, sampling at the right time, with reachable goals, and measuring you and not the car. Imagine you rely on a fitness tracker to tell you how much you've actually exercised. The number drives your decisions — whether you've done enough. For that number to mean anything, the tracker must actually measure your real activity, and there are several ways it fails. First, it might not be measuring at all — not worn, never started — so however hard you exercise, it reads zero. Second, it might measure at the wrong time — only while you sit still — so it under-counts. Third, it might have a goal you can never reach — steps in a twenty-fifth hour of the day — that never completes, impossible by construction. Those three make it read too low: you did the work, the number doesn't reflect it, and more exercise won't fix a tracker that isn't measuring you. But a fourth failure is worse, because it reads too high: the tracker is counting the wrong motion — the car's movement while you sit in traffic — so it reports you hit your goal while you did no exercise. That's the dangerous one: a low reading makes you do extra work, but a high reading from measuring the wrong thing makes you believe you're fit when you're not. The number looks great and means nothing. The tracker only tells you something true if it's on, sampling at the right time, with reachable goals, and measuring you and not the car.

So coverage is a fitness tracker of what was verified: the covergroup must measure the design's real behavior, and it fails in two directions. Reads too low (the hole that won't close): not sampled (tracker off — covergroup not constructed / .sample() never called); sampled at the wrong time (measuring while sitting — wrong instant); a bin that can never be hit (goal in the 25th hour — impossible by construction) — and more stimulus won't fix a measurement that isn't measuring. Reads too high (the dangerous over-report): counting the car, not your steps (measuring the testbench's stimulus, not the design's behavior — 100% achieved sitting in traffic); or a goal of "take 1 step" (bins too coarse — trivially met, meaningless). The discipline is the same: the number only means something if the tracker is on, well-timed, with reachable goals, measuring the design and not the testbench. Diagnose coverage by reading the report against the sampling points: a hole that won't close may be a tracker that's off, mis-timed, or chasing an impossible goal (not a stimulus gap), and suspiciously complete coverage may be counting the car instead of your steps (measuring the testbench, not the design) — check what is sampled, when, and on what. A coverage number means nothing until you confirm it's measuring the design.

Visual Explanation — the two directions of broken coverage

The defining picture is the two directions a coverage model can lie: under-reporting (a hole that won't close) and over-reporting (suspiciously complete).

The figure shows the two directions a broken coverage model lies. Under: never sampled / wrong time (brand-colored): covergroup not constructed or .sample() never called (0% everywhere), or sampled at the wrong instant — a sampling bug, not a stimulus gap. Under: unhittable bin / wrong variable (default-colored): a bin for a value the design can't produce, or a coverpoint on the wrong variable — no stimulus can close it. Over: measures the testbench, not the design (warning-colored — the dangerous one): samples the value you drove rather than the DUT's behavior — closes trivially, 100% means nothing. Over: bins too coarse (warning-colored): bins so broad any value hits them — trivially 100%, hiding the real holes. The crucial reading is the symmetry and the asymmetry: the two directions are symmetric as measurement errors (too low, too high), but asymmetric in danger. The under-report (top two) is visible (a hole stares at you) and wasteful (you chase stimulus that can't help) — but it errs safe: it says "not done" when you might be, so you do more work, not ship a bug. The warning-colored over-report (bottom two) is invisible (a green 100% looks like success) and dangerous: it says "done" when you're not, so you sign off and ship. This is why the over-report is highlighted: a measurement that reads too high is worse than one that reads too low, because too-low costs effort while too-high costs escaped bugs. The common thread across all four is that coverage measures something other than the design's actual behavior — nothing (not sampled), the wrong instant (wrong time), the impossible (unhittable), the wrong signal (wrong variable / the testbench), or too coarsely (coarse bins) — so the number doesn't reflect what the design did. The diagram is the coverage-lie map: under-report (won't close, wasteful) vs over-report (suspiciously complete, dangerous). A broken coverage model lies too low (a hole that won't close — a sampling or model bug, wasteful) or too high (suspiciously complete — measuring the testbench or coarse bins, dangerous false confidence).

RTL / Simulation Perspective — the causes and the sampling points

In code, each cause is a specific sampling or model defect, visible at the sampling point. The example shows the causes and the fixes.

// === The covergroup — and WHAT it samples is everything ===
class my_cov extends uvm_subscriber #(my_txn);
  my_txn tr;
  covergroup cg;
    cp_state: coverpoint tr.state { bins s[] = {[0:3]}; }   // ← WHAT variable? design or testbench?
  endgroup
  function new(string name, uvm_component parent);
    super.new(name, parent); cg = new();                     // ✓ construct the covergroup
  endfunction
  function void write(my_txn t);                             // called per observed transaction
    tr = t; cg.sample();                                     // ✓ sample at the right time, on observed data
  endfunction
endclass
 
// ✗ UNDER 1 — never sampled: cg = new() missing, or write()/sample() never called → 0% everywhere
// ✗ UNDER 2 — wrong time: cg.sample() before tr is valid, or on the wrong edge → records stale/X values
// ✗ UNDER 3 — unhittable bin: bins illegal = {4,5};  // design can never produce 4 or 5 → bin stays 0 forever
// ✗ UNDER 4 — wrong variable: coverpoint tr.local_copy;  // not the design state you meant → hole won't close
 
// ✗ OVER 1 — measures the TESTBENCH: sample the value the SEQUENCE drove, not the DUT's behavior
class bad_cov;
  covergroup cg_stim;
    cp: coverpoint seq.driven_value;   // ✗ the stimulus you generated — constrained-random hits all bins
  endgroup                              //   → 100% trivially, measures "did I drive it", NOT "did the DUT do it" (DebugLab)
endclass
// ✓ FIX: sample the DUT's OBSERVED behavior from the monitor, not the driven stimulus
 
// ✗ OVER 2 — bins too coarse: coverpoint tr.addr { bins all = {[0:$]}; }  // one bin → any addr hits → trivial 100%
// ✓ FIX: meaningful bins that distinguish the cases you care about
 
// === OBSERVE: read the coverage REPORT and the SAMPLING POINTS together ===
//   coverage report: which coverpoints/bins are 0 (holes) or 100 (suspiciously complete)
//   sampling points: is cg constructed? is sample() called, when, and on WHAT variable (design vs testbench)?

The code shows the causes and the sampling points. The covergroup cg samples tr.state per observed transaction (write → cg.sample()), constructed in new — and what it samples is everything. Under 1 (never sampled): cg = new() missing, or write/sample never called → 0% everywhere. Under 2 (wrong time): sample() before tr is valid or on the wrong edge → stale/X values. Under 3 (unhittable bin): bins illegal = {4,5} for values the design can't produce → stays 0 forever. Under 4 (wrong variable): coverpoint tr.local_copy instead of the design state → hole won't close. Over 1 (measures the testbench): coverpoint seq.driven_value — the stimulus you generated — constrained-random hits all bins → trivial 100%, measuring "did I drive it" not "did the DUT do it" (the DebugLab); fix: sample the DUT's observed behavior from the monitor. Over 2 (coarse bins): bins all = {[0:$]} — one bin → any addr hits → trivial 100%; fix: meaningful bins. Observe: read the coverage report (which bins are 0 or 100) and the sampling points (is cg constructed? is sample() called, when, and on what variable — design vs testbench?). The shape to carry: the covergroup's value and timing are the whole story — what it samples (design vs testbench, right vs wrong variable), when (right vs wrong instant), whether at all (constructed/sampled), and how finely (bins) — and both the report and the sampling points must be read together, because the report's number is meaningless without knowing what produced it. Read the coverage report against the sampling points — what is sampled, when, and on what variable — because the percentage is meaningless without knowing what produced it, and the most important check is that you sample the design's behavior, not the driven stimulus.

Verification Perspective — measuring the testbench is 100% that means nothing

The defining danger is the over-report from measuring the testbench — 100% coverage that verified nothing. Seeing how it produces false confidence clarifies why coverage must measure the design.

The figure shows measuring the testbench producing 100% that means nothing. A covergroup that samples the value the sequence drove measures the stimulus you generated, not the design's behavior. Constrained-random generates all the input values quickly, so this covergroup hits all its bins and reads 100% — fast and easy. But the design's actual behaviors — the states and responses the DUT produced — were never sampled, so whether the DUT exercised all of them is unmeasured. The verification insight is the disconnect between what closed and what was verified: the covergroup closed (100% on the driven values), but closing it required only that the testbench generate all inputs — which the constrained-random solver does trivially — not that the DUT exhibit all behaviors. So the 100% reflects the testbench's generator, not the design's coverage. A bug in an unexercised DUT behavior ships, despite 100% coverage, because the coverage measured the inputs you drove, not the design you were supposed to verify. This is the same false-confidence pattern as the silent scoreboard (27.4, checks nothing, passes green) and the zero-time green (27.6, runs nothing, passes green): a measurement that looks complete while measuring the wrong thing — here, 100% coverage that measured the testbench. The warning covergroup-on-stimulus → 100% path and the brand DUT-behavior → never-sampled path converge on false confidence. The crucial tell is what the covergroup points at: a coverpoint on a sequence's driven_value (a testbench variable) versus a coverpoint on a monitored DUT signal (the design's behavior) — and coverage that closes suspiciously easily is a red flag that it's measuring the generator, not the design. The crucial discipline is that coverage must sample the design's observed behavior, from the monitor, not the stimulus you drove — and closing fast should raise suspicion, not confidence. The diagram is the false-100% mechanism: covergroup on the driven stimulus → trivially 100% → design behavior never sampled → false confidence. A covergroup that samples the driven stimulus hits 100% trivially while the design's behavior goes unmeasured — coverage must measure the design's observed behavior, not the testbench's generated stimulus, and coverage that closes suspiciously easily is measuring the wrong thing.

Runtime / Execution Flow — diagnosing a coverage issue

At run time, diagnosing a coverage issue follows the methodology, branching on won't-close versus suspiciously-complete and reading the report against the sampling points. The flow shows it.

The flow shows the direction-driven diagnostic. Read the symptom (step 1): a hole that won't close despite stimulus, or coverage that closed suspiciously fast. Won't close → check the sampling (step 2): sampled at all (0% = not sampled), right time, bin hittable, right variable. Suspiciously complete → check what is sampled (step 3): design behavior vs driven stimulus, and meaningful bins vs too coarse. Confirm → fix (step 4): sample the design variable at the right time, remove unhittable bins, refine coarse bins. The runtime insight is that both directions require reading the coverage report together with the sampling points — the report alone is insufficient (it shows the percentage but not what produced it). For the won't-close direction, the report shows which bin is 0, but the sampling points reveal whether the covergroup is even sampled (a 0% across the entire covergroup is a strong sign of "not sampled", not a stimulus gap), when it samples, and on what variable. For the suspiciously-complete direction, the report shows 100%, but only the sampling points reveal the crucial fact — is it sampling the design or the testbench? — which determines whether the 100% means anything. So the diagnostic is always "read the number, then read what produced it." The crucial heuristic in step 1 is to be suspicious of fast closure: coverage that closes easily is as much a red flag as a hole that won't close — both are symptoms of a broken model (the over and the under), and the fast-closing one is the more dangerous precisely because it doesn't look like a problem. The brand (symptom) → success (under-check) / warning (over-check) → warning (fix) flow shows the two branches and the shared confirmation. The flow is the coverage diagnostic: symptom direction → check the sampling points → confirm against the report → fix. Diagnose a coverage issue by reading the report with the sampling points — a hole that won't close needs the covergroup checked for being sampled, well-timed, hittable, and on the right variable; suspiciously complete coverage needs checking whether it samples the design or the testbench — and fast closure is as suspect as a stuck hole.

Waveform Perspective — coverage tracking the wrong signal

The over-report is visible: the covergroup samples the driven stimulus (which reaches all values), while the DUT's actual state (a different signal) never reaches some states. The waveform shows coverage tracking the wrong signal.

The waveform shows coverage tracking the wrong signal. The covergroup samples the driven stimulus value (drive_val), which the sequence cycles through all four values (0,1,2,3), so the covergroup hits every bin and reads 100%. But the DUT's actual state (dut_state) only ever reaches 0 and 1 — states 2 and 3 are never produced by the design under this stimulus. Those are real coverage holes, but the covergroup does not see them, because it's sampling the driven stimulus, not the DUT state. The crucial reading is the divergence between the two signals: drive_val spans all four values (so the covergroup, watching it, reads 100%), while dut_state spans only two (so the design has uncovered states). The covergroup's 100% reflects drive_val, which is not the thing you wanted to cover — you wanted to cover dut_state (the design's behavior), and that has holes (2,3) the covergroup is blind to. So the 100% is true about the wrong signal and false about the design. The picture to carry is that coverage is only as meaningful as the signal it samples: watching drive_val tells you "the testbench drove all values" (which the generator does easily); watching dut_state would tell you "the design reached all states" (which it didn't) — and only the latter is verification coverage. Reading the waveform this way — which signal is the covergroup sampling, and does that signal's full range mean the design was covered? — exposes the over-report: the covergroup's full range on drive_val hides the design's holes on dut_state. The covergroup reaching 100% on a stimulus signal while a monitored design signal sits in a subset of its states is the waveform signature of *coverage measuring the testbench, not the design. Coverage that reads 100% on the driven stimulus while the DUT's actual state never reaches some states is measuring the wrong signal — the covergroup must sample the design's behavior, because a stimulus signal's full range hides the design's real holes.

DebugLab — the 100% coverage that measured the testbench, not the design

✗ COVERGROUP ON THE DRIVEN STIMULUS — measures the testbench, not the design:
  covergroup cg_mode;
    cp_mode: coverpoint seq.mode;   // ✗ the mode the SEQUENCE randomized and drove
  endgroup
  // constrained-random generates all mode values in the first few transactions → cg_mode = 100% FAST
  // → measures "did I drive every mode?" (trivially yes), NOT "did the DUT exercise every mode?"
  // → in-mode design behavior never sampled → a bug in one mode ships under a green 100% (DebugLab)
 
✓ COVERGROUP ON THE DESIGN'S OBSERVED BEHAVIOR — measures the design:
  class mode_cov extends uvm_subscriber #(mode_txn);   // fed from the MONITOR
    covergroup cg_mode;
      cp_mode: coverpoint observed.dut_mode;           // ✓ the DUT's actual operating mode, observed
      // (+ cross with the in-mode behaviors that must be exercised per mode)
    endgroup
    function void write(mode_txn t); observed = t; cg_mode.sample(); endfunction
  endclass
  // → now 100% means the DUT actually exercised every mode (and behavior), not just that you drove them

Common Mistakes

• Sampling the driven stimulus instead of the design's behavior. A covergroup on the value you drove closes trivially and measures the testbench; sample the DUT's observed behavior from the monitor.
• Trusting fast 100% coverage. Suspiciously easy closure often means measuring the wrong thing; treat it as a red flag, not success.
• Chasing stimulus for a hole that's a sampling bug. A covergroup never sampled, sampled at the wrong time, or with an unhittable bin won't close no matter the stimulus; check the sampling points first.
• Bins so coarse anything hits them. A single broad bin reads trivially 100% and hides the real holes; define meaningful bins that distinguish the cases you care about.
• Reading the percentage without the sampling points. The number is meaningless without knowing what is sampled, when, and on what variable; read the report and the sampling points together.
• Unhittable bins counted as real holes. A bin for a value the design can't produce will never close; remove it or mark it illegal rather than chasing it.

Senior Design Review Notes

Interview Insights

Exercises

1. Classify the failure. For each — coverage at 0% across a whole covergroup; a single bin stuck at 0; a covergroup at 100% after three transactions — name the likely cause and what to check.
2. Point it at the design. Given a covergroup sampling seq.mode, rewrite it to sample the DUT's observed mode from the monitor and explain what changes about the meaning of 100%.
3. Hittable or not. Given a bin stuck at zero, describe how you'd determine whether it's a real hole or an unhittable bin, and the different fix for each.
4. Refine the bins. Given a coverpoint with one broad bin reading 100%, propose meaningful bins and explain what holes they would reveal.

Summary

• Coverage issues are failures of the coverage model as a measurement — it lies in two directions: under-reporting (a hole that won't close) or over-reporting (suspiciously complete) — so coverage doesn't measure what was actually verified.
• The under-report causes (a hole that won't close from a measurement bug, not a stimulus gap): covergroup never sampled (0% everywhere), sampled at the wrong time, an unhittable bin, or coverage on the wrong variable — no stimulus can close them.
• The over-report causes (suspiciously complete): measuring the testbench's driven stimulus rather than the design's behavior (closes trivially, 100% means nothing), or bins too coarse (any value hits them).
• The crucial asymmetry: the under-report wastes effort (chasing stimulus), but the over-report is dangerous — false confidence (100% that verified nothing), like the silent scoreboard and zero-time green; coverage must measure the design's behavior, not the testbench's stimulus, and fast closure is a red flag.
• The durable rule of thumb: coverage is a measurement that lies in two directions — too low (a hole that won't close because the covergroup isn't sampled, is mis-timed, has an unhittable bin, or covers the wrong variable, so stimulus can't help) or too high (suspiciously complete because it samples the testbench's driven stimulus rather than the design's behavior, or uses coarse bins) — so read the coverage report together with the sampling points (is it sampled, when, and on what variable?), sample the design's observed behavior from the monitor not the stimulus you drove, treat fast 100% as a red flag, and remember the over-report is the dangerous one because 100% that measured the wrong thing ships bugs.

Next — Environment Bring-Up Debug: the module closes on the hardest debugging context — a brand-new environment that doesn't work yet, where many of these failures coexist. How to bring up a UVM environment from nothing systematically: establishing signs of life layer by layer (clock and reset, interface connection, a single transaction end to end, then checking and coverage), isolating the first failure before the next, and turning a silent, non-working testbench into one that drives, checks, and measures — so the methodology and the specific failure modes come together into a bring-up discipline.