Coverage Bins

Functional Coverage · Module 19 · Page 19.4

The Engineering Problem

The previous chapter established that a coverpoint's meaning comes from its partition into bins (Module 19.3) — and that the art is choosing a meaningful partition. But "bin" is not one thing: SystemVerilog gives bins a rich vocabulary, and which kind you use precisely controls what the coverpoint requires, excludes, and forbids. A single range bin (bins b = {[1:4]}) and an array of bins (bins b[] = {[1:4]}) look almost identical but mean opposite things — one bin hit by any value 1–4, versus four bins each requiring its own value. A transition bin (bins t = (1 => 2 => 3)) measures a sequence over time, not a value. An ignore bin removes a value from the coverage denominator; an illegal bin turns a value into a runtime error. Confuse these and the coverpoint measures the wrong thing: it can never close (a required bin for an unreachable value), or it misses a violation (a forbidden value with no illegal bin). The problem this chapter solves is the bin vocabulary: the kinds of bins and the three jobs — require, exclude, forbid — so a coverpoint counts exactly what it should.

A bin is a named bucket with a rule that classifies a sampled value — and bins have three jobs. Require (counting bins): a bin is hit when the value matches its rule, and the coverpoint is covered when all its counting bins are hit. The rule can be a value ({5}), a range ({[1:4]}, hit by any value in range), a list ({1,5,9}), an array (bins b[] — one bin per value, the precise form of 19.3's "carve the cases"), a wildcard ({4'b1??0} — pattern match), or a transition ((1 => 2 => 3) — a value sequence over successive samples). Automatic bins (one per value, capped by auto_bin_max) are the default for small enumerations. Exclude (ignore_bins): values removed from coverage — not counted, not required — for reserved or unreachable values, so the coverpoint can close. Forbid (illegal_bins): values that should never occur — if sampled, a runtime error fails the test (a check, not a measure). This chapter is the bin vocabulary: automatic vs explicit, value/range/list/array, wildcard, transition, and the require/exclude/forbid trichotomy that makes a coverpoint count exactly what it should.

What are the kinds of coverage bins — automatic versus explicit, value, range, list, array, wildcard, and transition — and what are the three jobs of a bin (require with counting bins, exclude with ignore_bins, forbid with illegal_bins) that precisely control what a coverpoint counts?

Motivation — why the bin vocabulary is worth mastering

Bins are small syntax with large consequences — the difference between a coverpoint that means what you think and one that silently misleads. The reasons:

• The bin kind determines what's required. bins b[] (array — one per value) requires every value; bins b (single — one for all) requires just one. The same-looking declaration means opposite things, and getting it wrong gives trivial (false 100%) or unattainable coverage.
• Some scenarios are sequences, not values. A state machine transition, a mode change, a back-to-back pattern — these are temporal and can only be measured by transition bins (a => b => c). Without them, you can't express sequence coverage.
• Not every value is reachable or legal. Some values are reserved (the DUT never produces them) — they must be ignore_bins, or the coverpoint never closes. Some are forbidden (must never occur) — they should be illegal_bins, so a violation fails the test instead of silently passing.
• Automatic bins are a trap on wide variables. Auto bins are convenient for small enums but catastrophic on wide fields (capped at auto_bin_max, lumping values into meaningless buckets) — knowing when auto bins apply prevents the 19.3 anti-patterns.
• Bins are how the plan's exclusions and rules are encoded. The coverage plan says not just what to exercise but what to exclude (reserved) and what's illegal (forbidden) — the bin vocabulary (counting / ignore / illegal) is how those are expressed.

The motivation, in one line: bins are small syntax with large consequences — the kind of bin (value/range/array/wildcard/transition) precisely determines what a coverpoint requires, and the three jobs (require / exclude / forbid via counting / ignore_bins / illegal_bins) determine whether a coverpoint can close, measures sequences, and catches forbidden values — so mastering the vocabulary is what makes a coverpoint count exactly what the plan intends.

Mental Model

Hold bins as the rules of a sorting machine — each sample is routed to a bucket, discarded, or trips an alarm:

Bins are the rules of a sorting machine: each sampled value drops in and is routed to the bucket whose rule it matches — an exact value, a range, a pattern, or a completed sequence — and the coverpoint is "covered" when every counting bucket has caught at least one item. Two special rules don't count: an ignore rule quietly discards the item (it's not required and not counted), and an illegal rule trips an alarm (the value should never have appeared, so the test fails). The art is writing the rules so each bucket catches exactly the cases that matter. Picture a sorting machine on a conveyor (the coverpoint). Each sampled value drops onto the belt and is routed by a set of rules (the bins). The counting rules send the item to a labeled bucket: an exact-value rule (this bucket catches only 5), a range rule (this bucket catches anything 1–4 — so one item 1–4 fills it, regardless of which), a list rule (catches 1, 5, or 9), a pattern rule (catches anything matching 1??0 — the ? bits don't matter), or a sequence rule (catches an item only when it completes a tracked sequence — the belt remembers the last few items, and fires when it sees 1-then-2-then-3). An array of buckets is the key subtlety: bins b[] over 1–4 makes four separate buckets (one per value, each must be filled), whereas a single bins b over 1–4 makes one bucket (any of the four fills it). The coverpoint is "covered" when every counting bucket has caught at least one item. Then two special rules don't count. An ignore rule quietly discards the item — it's not required and not counted (used for reserved values the machine will never see anyway, so they don't block the "all buckets filled" check). An illegal rule trips an alarm — the value should never have appeared on the belt, so seeing it halts the line (the test fails). The art is writing the rules so each bucket catches exactly the cases that matter — and so the ignore and illegal rules correctly discard the unreachable and flag the forbidden.

So bins are sorting rules: counting rules route each value to a bucket (by exact value, range, list, pattern, or completed sequence), an array of buckets requires each value (versus a single bucket for all), and the coverpoint is covered when every counting bucket is filled. Two rules don't count: ignore discards (unreachable/reserved — so it doesn't block closure) and illegal alarms (forbidden — so it fails the test). Write the rules so each bucket catches exactly what matters, discard the unreachable, and alarm on the forbidden.

Visual Explanation — the three jobs of a bin

The defining picture is the trichotomy: bins require (counting), exclude (ignore), or forbid (illegal) — and the counting job has a vocabulary of rules.

The figure shows the three jobs of a bin. Require — counting bins (the brand-colored top): a bin is hit when the value matches its rule, and the coverpoint is covered when all are hit. The rules: a value bin ({5}), a range bin ({[1:4]}), an array of bins (b[] — one per value), a wildcard bin ({1??0} — pattern), or a transition bin ((1=>2=>3) — a sequence over time). Exclude — ignore_bins (the success-colored middle): values removed from coverage — not counted, not required — for reserved or unreachable values, so the coverpoint can close. Forbid — illegal_bins (the warning-colored bottom): values that must never occur — if sampled, a runtime error fails the test (a check, not a measure). The crucial reading is that these three jobs are distinct and you must pick the right one per value. A value the DUT legally produces and you want to exercise → a counting bin. A value the DUT legally never produces (reserved) → an ignore bin (else the coverpoint never closes, chasing an unreachable value). A value that must never occur (a protocol violation) → an illegal bin (else the violation passes silently). Putting a value in the wrong job breaks the measurement: ignore where illegal was needed misses a violation; a counting bin where ignore was needed blocks closure; illegal where counting was needed fails a legal test. The counting job's vocabulary (value / range / array / wildcard / transition) then precisely specifies what counts. The diagram is the bin decision: for each value of the variable, decide require (and which counting rule), exclude, or forbid — and the coverpoint counts exactly what those rules say. Every value gets a job: require it, exclude it, or forbid it.

RTL / Simulation Perspective — the bin vocabulary in code

In code, the bin kinds are distinct syntax inside the coverpoint braces. The example shows the full vocabulary: auto, value, range, list, array, wildcard, transition, ignore, and illegal.

covergroup txn_cg with function sample(bus_txn t);
 
  // AUTOMATIC bins — one per value, capped by auto_bin_max (default 64). Good ONLY for small enums.
  cp_op: coverpoint t.op;                      // auto: one bin per op value
 
  // EXPLICIT counting bins — VALUE, RANGE, LIST
  cp_len: coverpoint t.len {
    bins one     = {1};                        // VALUE bin: hit when len == 1
    bins midrange= {[2:14]};                   // RANGE bin: hit by ANY len in 2..14 (one bin)
    bins powers  = {1, 2, 4, 8, 16};           // LIST bin: hit by any listed value
  }
 
  // ARRAY of bins — ONE BIN PER VALUE (each must be hit) — the precise "carve every case"
  cp_id: coverpoint t.id {
    bins each[] = {[0:7]};                      // 8 SEPARATE bins id[0]..id[7]; ALL must be hit
  }
 
  // WILDCARD bin — pattern with don't-care bits
  cp_code: coverpoint t.code {
    wildcard bins burst = {4'b1??0};           // matches 1000,1010,1100,1110 (the ? bits don't matter)
  }
 
  // TRANSITION bins — a SEQUENCE of values over SUCCESSIVE samples (temporal)
  cp_state: coverpoint t.state {
    bins idle_to_done = (IDLE => BUSY => DONE); // hit when state goes IDLE then BUSY then DONE
    bins ping_pong    = (A => B), (B => A);     // either transition
  }
 
  // IGNORE bins — EXCLUDE reserved/unreachable values (not counted, not required → can close)
  cp_mode: coverpoint t.mode {
    bins legal[]    = {[0:2]};
    ignore_bins rsvd = {[3:7]};                 // reserved: DUT never produces → don't block closure
  }
 
  // ILLEGAL bins — FORBID values that must never occur (sampling one FAILS the test)
  cp_resp: coverpoint t.resp {
    bins ok = {OKAY}; bins err = {SLVERR, DECERR};
    illegal_bins reserved_resp = {2'b10};       // this encoding must never appear → runtime error
  }
 
endgroup

The code shows the full bin vocabulary. Automatic (cp_op: coverpoint t.op; — no braces) — one bin per value, capped by auto_bin_max (default 64); good only for small enums. Value/range/list (cp_len): a value bin (one = {1}, hit when len == 1), a range bin (midrange = {[2:14]}, hit by any len in 2–14 — one bin), a list bin (powers = {1,2,4,8,16}, hit by any listed value). Array (cp_id: bins each[] = {[0:7]}) — eight separate bins id[0]..id[7], all must be hit — the precise "carve every case" of 19.3. Wildcard (cp_code: wildcard bins burst = {4'b1??0}) — pattern match, the ? bits don't matter (matches 1000, 1010, 1100, 1110). Transition (cp_state): a sequence over successive samples — idle_to_done = (IDLE => BUSY => DONE) is hit when state goes through that order; ping_pong = (A => B), (B => A) for either transition. Ignore (cp_mode: ignore_bins rsvd = {[3:7]}) — reserved values excluded (the DUT never produces them, so they don't block closure). Illegal (cp_resp: illegal_bins reserved_resp = {2'b10}) — a forbidden encoding; sampling one is a runtime error that fails the test. The shape to carry: the counting bins (value / range / list / array / wildcard / transition) specify what to require with increasing power (single value → pattern → sequence), ignore_bins specify what to exclude, and illegal_bins specify what to forbid. The array bins b[] vs single bins b distinction is the most error-prone: b[] = one bin per value (each required), b = one bin for all (any one suffices). Pick the bin kind that makes the coverpoint require, exclude, and forbid exactly the right values.

Verification Perspective — array bins versus a single bin

The single most consequential bin distinction is array (b[]) versus single (b) — identical-looking syntax, opposite meaning. Seeing them side by side prevents the most common false-100% bin bug.

The figure shows the array-versus-single distinction. A single bin over a range (bins b = {[0:7]}) creates one bin, hit by any value in the range — so one transaction covers it, regardless of which value occurred → trivial 100%. An array of bins over the same range (bins b[] = {[0:7]}) creates a separate bin per value (b[0]..b[7]) — so every value must occur for the coverpoint to close → meaningful 100% (all 8 exercised). The verification insight is that this near-identical syntax — just the [] — means opposite things: b requires one value (of the range), b[] requires all. The warning-colored single bin is the trap: it looks like it covers "the range 0–7," but it only requires one of them, reaching 100% on the first transaction (the false-100% of 19.3, now pinned to a specific syntax error). The brand/success-colored array bin is usually what you want when the values are an enumeration (IDs, modes, opcodes) where each is a distinct case to exercise. So the choice of b vs b[] is the choice of "require one" vs "require all" — and it's the most common place a coverpoint silently reads a misleading 100%. The skill is asking: "do I need every value of this set exercised (b[]) or just any one (b)?" For an enumeration of distinct functional cases → b[]. For a range that's functionally uniform (and you just want some representative) → b. The diagram is the array decision: b (one bucket, any value, trivial 100%) versus b[] (one bucket per value, all required, meaningful 100%) — the [] is the difference between requiring one and requiring all. When each value is a distinct case, use b[]; a single b over a set requires only one of them.

Runtime / Execution Flow — ignore versus illegal at run time

At run time, ignore and illegal bins behave very differently — one silently excludes, the other actively fails. The flow shows what each does when a value is sampled.

The flow shows ignore versus illegal at run time. Value sampled (step 1): the coverpoint receives the variable's current value and routes it by the bin rules. Counting bin (step 2): if it matches a value/range/array/wildcard/transition bin, that bin is marked hit and contributes to coverage. Ignore bin (step 3): if it matches ignore_bins, it is silently excluded — not counted, not required, removed from the denominator. Illegal bin (step 4): if it matches illegal_bins, a runtime error fires and the test fails — the value should never have occurred. The runtime insight is the opposite behaviors: ignore_bins is passive (it quietly removes a value from consideration, so that value can never block closure and never appears as an unhit requirement), while illegal_bins is active (it watches for a forbidden value and fails the test the instant one appears). This is why the job you assign a value matters so much: a reserved value as ignore_bins lets the coverpoint close (correct); the same value left in a counting bin blocks closure forever (wrong — chasing an unreachable value); a forbidden value as illegal_bins catches the violation (correct); the same value ignored lets the violation pass silently (wrong — a missed check). So ignore_bins and illegal_bins are not interchangeable — one excludes from the measure, the other adds a check. The flow is the routing: a sampled value either counts (counting bin), vanishes from the measure (ignore), or fails the test (illegal) — three fates, chosen by which job you gave that value. Ignore quietly excludes the unreachable; illegal actively fails on the forbidden — never swap them.

Waveform Perspective — transition bins over time

The transition bin is uniquely temporal — it's hit only when the variable passes through a sequence of values over successive samples. The waveform shows a transition completing, and a forbidden value tripping an illegal bin.

The waveform shows the transition bin's temporal nature and the illegal bin's check. The state variable is sampled each transaction. The transition bin (IDLE => BUSY => DONE) is hit only when state passes through that exact sequence over three successive samples — it completes at the third sample (trans_hit at sample 3, when state=DONE after IDLE then BUSY). The crucial reading is that no single value hits a transition bin — the sequence must occur in order across samples: IDLE alone doesn't hit it, nor BUSY, nor DONE — only the completed IDLE→BUSY→DONE does. This is coverage of a temporal pattern — a state-machine path, a protocol sequence — that value bins cannot express. Later, state takes a forbidden value (RSVD, covered by an illegal_bins) — the moment it's sampled, a runtime error fires and the test fails (illegal_fire at sample at cycle 8). The picture to carry is the two distinct behaviors: the transition bin accumulates across samples and fires when the sequence completes (a temporal require), while the illegal bin fires the instant a forbidden value appears (a temporal forbid — a check). Reading the waveform this way — did the sequence complete (transition hit)? did a forbidden value appear (illegal fire)? — is reading the temporal bins. The transition completing at the third sample is the signature of sequence coverage; the illegal firing on RSVD is the signature of a forbidden-value check. Together they show that bins measure not only which values occurred but in what order (transition) and whether a forbidden value ever appeared (illegal). Transition bins require a sequence over time; illegal bins fail the instant a forbidden value occurs.

DebugLab — the coverpoint that could never close

✗ AUTO bins require ALL 8 values, including 3 the DUT can never produce:
  cp_mode: coverpoint t.mode;          // auto: bins for 0,1,2,3,4,5,6,7 — ALL required
  // modes 5,6,7 are RESERVED — the DUT never produces them → those 3 bins NEVER hit
  // coverage capped at 5/8 = 62%... or with weighting, stuck at 94% — NEVER 100%
  // the team chases unreachable values forever; closure is impossible
 
✓ IGNORE the unreachable values so the coverpoint counts only what's reachable:
  cp_mode: coverpoint t.mode {
    bins legal[]     = {[0:4]};         // the 5 modes the DUT actually produces — each required
    ignore_bins rsvd = {[5:7]};         // reserved: excluded from coverage → don't block closure
  }
  // now the denominator is the 5 REACHABLE modes; exercising all 5 → 100% → closure achievable
  // (if 5,6,7 must NEVER occur, use illegal_bins instead — then producing one FAILS the test)

Common Mistakes

• Confusing bins b with bins b[]. A single bin over a range requires one value (trivial 100%); an array requires every value — use b[] when each value is a distinct case.
• Auto bins on a wide or partially-reserved variable. Auto bins require every value (including reserved ones) and cap at auto_bin_max — use explicit bins plus ignore_bins.
• Leaving unreachable values as counting bins. A reserved value the DUT never produces blocks closure forever; exclude it with ignore_bins.
• Using ignore_bins where illegal_bins was needed. A forbidden value silently ignored lets a violation pass; use illegal_bins so it fails the test.
• Forgetting transition bins for sequences. A temporal scenario (state path, mode change) can only be measured by transition bins, not value bins.
• Not using wildcard bins for don't-care bits. A pattern with don't-care bits is cleanly expressed as a wildcard bin, not enumerated value by value.

Senior Design Review Notes

Interview Insights

Exercises

1. Choose b or b[]. For an 8-entry ID field where every ID must be exercised, write the bin declaration and explain why the other form would mislead.
2. Assign the jobs. For a 3-bit mode field with modes 0–4 used, 5–6 reserved, and 7 forbidden, write the counting, ignore, and illegal bins.
3. Write a transition. Express coverage of a state machine path idle → active → flush → idle as a transition bin.
4. Fix the stuck coverpoint. A coverpoint is stuck at 88% across all seeds. List the steps to determine whether the unhit bins are unreachable.

Summary

• A bin is a named bucket with a rule that classifies a sampled value, and bins have three jobs: require (counting bins), exclude (ignore_bins), and forbid (illegal_bins).
• Counting bins have a vocabulary: a value ({5}), a range ({[1:4]} — any value in range), a list ({1,5,9}), an array (bins b[] — one bin per value, all required, vs bins b — one for all, trivially hit), a wildcard ({1??0} — pattern), or a transition ((a => b => c) — a sequence over time).
• ignore_bins excludes values from coverage (reserved/unreachable — not counted, not required, so the coverpoint can close); illegal_bins forbids values (must never occur — sampling one fails the test, a check).
• Automatic bins (one per value, capped by auto_bin_max) are the default for small enumerations but meaningless on wide variables and block closure on partially-reserved ranges — use explicit bins with the right jobs.
• The durable rule of thumb: every value of a variable needs the right bin job — reachable values you want to exercise go in counting bins (and use b[] not b when each value is a distinct case), values the DUT legally never produces go in ignore_bins so the coverpoint can close, and values that must never occur go in illegal_bins so a violation fails the test; a coverpoint stuck below 100% is often requiring an unreachable value, and a missed violation is often a forbidden value with no illegal bin.

Next — Cross Coverage: the most powerful — and most explosive — coverage construct: the cross. Measuring not just each variable alone but their combinations — every operation at every size, every mode in every state — why crosses matter (bugs hide in combinations), how the combination space explodes, and how to control it with bin selection and ignore bins so a cross measures the meaningful combinations rather than an unclosable product.