Coverpoints

Functional Coverage · Module 19 · Page 19.3

The Engineering Problem

The covergroup (Module 19.2) is the container — declared, instantiated, and sampled. But a container measures nothing on its own; what it holds — the coverpoints — are where the actual measurement happens. A coverpoint targets a single variable (or expression) and records which of its values were seen — it's the atom of functional coverage, the one feature a covergroup tracks. And here is where the intent of coverage lives: a coverpoint's meaning comes entirely from how its value space is partitioned into bins. The same variable can be measured uselessly (auto-bins on a 32-bit address → billions of meaningless buckets that never close) or meaningfully (a few functionally-distinct bins — aligned/unaligned, boundaries, ranges). Worse, a coarse partition can read 100% while the case that matters was never separately exercised — false confidence at the coverpoint level. The problem this chapter solves is the coverpoint: how it measures one variable, how values map to bins, and the art of choosing the meaningful partition so the measurement means something.

A coverpoint measures a single variable or expression, recording which of its values were seen by partitioning its value space into bins — a bin is hit when the variable takes a value in it, and the coverpoint's coverage is the fraction of its bins hit. It is the atom of coverage: one coverpoint = one feature (e.g. coverpoint t.op measures which operations occurred). Each sample of the covergroup captures every coverpoint's current value and records it into the matching bin. The art is the partition: bins should capture the functionally-distinct cases — boundaries (min, max), meaningful ranges (small/large), special values (aligned/unaligned, error/ok) — not every raw value (a 32-bit field has billions, and auto-bins over them are meaningless and never close). Coverpoints can target expressions (t.addr[1:0] for alignment) and be guarded (iff — sample only when valid). A set of coverpoints in a covergroup is the coverage plan's features, encoded. Critically, a coverpoint is only as meaningful as its bins — a too-coarse partition reaches 100% trivially while missing the corner, the false confidence of 19.1 at the coverpoint granularity. This chapter is the coverpoint: one-variable measurement, value-to-bin mapping, the art of the partition, and how coverpoints encode the plan's features.

What is a coverpoint — how does it measure a single variable, how do that variable's values map to bins, what makes a partition meaningful (rather than raw range or too coarse), and how does a set of coverpoints encode the features the plan says to exercise?

Motivation — why the coverpoint's partition is where the intent lives

The covergroup is plumbing; the coverpoints are where the verification intent is expressed. The reasons the partition matters:

• The coverpoint is the unit of measurement. The covergroup samples, but each coverpoint is what records a value — which of its variable's values were seen. Coverage is computed per coverpoint (fraction of bins hit), then aggregated.
• The bins define what "covered" means. A coverpoint's coverage is entirely determined by its bins — so how you partition the variable defines what it means to have "covered" it. The partition is the specification of what to exercise.
• Raw range is meaningless; meaningful partition is the art. A wide variable (32-bit) has too many raw values to bin one-per-value — the coverage would never close and would measure nothing functional. The art is choosing the functionally-distinct cases — the boundaries, ranges, and special values that matter.
• Too-coarse bins give false 100%. The opposite error: one bin for a whole range reaches 100% on the first sample — trivially — while never checking that the corner (the max, the special value) was exercised. 100% on a coarse coverpoint means nothing.
• Coverpoints encode the plan. The coverage plan (19.1) lists features to exercise; each becomes a coverpoint (or a cross). So the set of coverpoints is the plan, made executable — reading the coverpoints tells you what the verifier decided matters.

The motivation, in one line: the covergroup samples, but the coverpoint is where the measurement and the intent live — its partition into bins defines what "covered" means, so the art of choosing the functionally-distinct cases (boundaries, ranges, special values — not raw range, not one coarse bin) is what makes a coverpoint meaningful, and a set of well-partitioned coverpoints is the coverage plan, encoded and executable.

Mental Model

Hold a coverpoint as one question on the covergroup's tally sheet, with bins as its answer buckets — and the art is asking the right question with the right buckets:

A coverpoint is one question on the covergroup's tally sheet — "which values of this one variable did we see?" — and its bins are the answer buckets. Each sample drops a tally into the bucket matching the variable's current value. The coverpoint is covered when every bucket has at least one tally, and the whole point rests on choosing buckets that capture the functionally-distinct cases: too many buckets (one per raw value) and you never fill them all; too few (one bucket for everything) and you fill it trivially while learning nothing. Recall the covergroup as a structured tally sheet (Module 19.2). A coverpoint is one column — one question — on that sheet, say "which operation?" or "which size?". Under the question are answer buckets (the bins): for "which operation?", the buckets read, write, RMW; for "which size?", perhaps small, large, boundary. Each time the covergroup is sampled, this coverpoint looks at its variable's current value and drops a tally into the bucket that value falls in. The coverpoint is "covered" when every bucket has at least one tally — every answer was seen at least once. Now, the entire usefulness rests on choosing the buckets well. If you make too many buckets — one per raw value of a 32-bit field — you'd need billions of tallies to fill them all, so the column never fills and the measurement is useless. If you make too few — one bucket labeled "any value" — then the very first tally fills it, the column reads "covered" immediately, and you've learned nothing (you never checked whether the max value, or the special case, ever occurred). The art is the middle: buckets that carve the variable at its functionally-meaningful seams — the boundaries (min, max), the ranges that behave differently (small vs large), the special values (aligned vs unaligned, error vs ok). Those buckets, filled, mean something: every functionally-distinct case was exercised. So a coverpoint is one question with well-chosen answer buckets — and the quality of the coverpoint is the quality of the buckets.

So a coverpoint is one question on the tally sheet, with bins as answer buckets: each sample drops a tally in the bucket matching the value, and the coverpoint is covered when every bucket is filled. The art is choosing buckets at the functionally-distinct seams — not one-per-raw-value (never fills, useless), not one-bucket-for-all (fills trivially, meaningless), but the boundaries, ranges, and special values that matter. A coverpoint is only as good as its buckets: ask the right question, and partition the answer into the cases that are functionally distinct.

Visual Explanation — a coverpoint partitions one variable into bins

The defining picture is the partition: a coverpoint takes one variable and splits its value space into bins, each hit when the value lands in it.

The figure shows a coverpoint as a partition. The coverpoint (cp_size, the brand-colored center) targets a single variable (size) and splits its value space into bins: small (values 1–4), large (values 5–63), and a boundary bin (max, value == 64). When the covergroup is sampled, the coverpoint maps the variable's current value to the bin it falls in and marks that bin hit: a size of 3 hits small, a size of 30 hits large, a size of 64 hits max. The coverpoint is covered when all its bins are hit. The crucial reading is that the partition is a design choice — here, the verifier decided that size has three functionally-distinct cases worth tracking: the small range, the large range, and the boundary (the maximum, the most likely to expose an off-by-one or overflow bug — hence the warning-colored bin, the corner that matters). A different partition (e.g. one bin for all of 1–64, or 64 bins one-per-value) would measure something different — coarser (trivially 100%) or finer (never closes). The boundary bin (max == 64, separated from the large range) is the key design decision: by carving out the maximum into its own bin, the coverpoint requires that size == 64 be exercised specifically before it reads 100% — otherwise a large bin covering 5–64 would read hit on size == 7 without ever testing the boundary. The diagram is the anatomy of measurement: one variable → a chosen partition → bins hit by the values that land in them → covered when all bins are hit. The partition — small / large / boundary — is the coverpoint's specification of what to exercise. A coverpoint is a variable plus a partition; the partition is where the intent lives.

RTL / Simulation Perspective — declaring coverpoints and their bins

In code, a coverpoint is one line inside a covergroup — coverpoint <variable> { <bins> } — and its bins are what give it meaning. The example shows coverpoints with auto bins, explicit bins, expression targets, and a guard.

covergroup txn_cg with function sample(bus_txn t);
 
  // simplest: AUTO bins — one bin per enum value (good for SMALL enumerations)
  cp_op: coverpoint t.op { bins ops[] = {READ, WRITE, RMW}; }   // 3 meaningful bins
 
  // EXPLICIT bins — partition a numeric range into FUNCTIONALLY-DISTINCT cases (the art)
  cp_size: coverpoint t.size {
    bins small    = {[1:4]};      // small range
    bins large    = {[5:63]};     // large range
    bins max_size = {64};         // BOUNDARY carved out → must be hit specifically (Figure 1)
  }
 
  // EXPRESSION coverpoint — measure a DERIVED feature, not a raw field
  cp_align: coverpoint t.addr[1:0] { bins aligned = {0}; bins unaligned = {[1:3]}; }
 
  // GUARDED coverpoint — sample only when the value is MEANINGFUL (iff condition)
  cp_resp: coverpoint t.resp iff (t.valid) { bins ok = {OKAY}; bins err = {SLVERR, DECERR}; }
 
  // ✗ ANTI-PATTERN: auto bins on a WIDE variable → billions of meaningless bins, never closes
  // cp_addr: coverpoint t.addr;   // 32-bit → auto_bin_max buckets of nonsense — DON'T
 
endgroup
// each coverpoint measures ONE variable; its BINS define what "covered" means for that feature

The code shows coverpoints as one-variable measurements, defined by their bins. Auto bins (cp_op with bins ops[] = {READ, WRITE, RMW}) — one bin per value, good for small enumerations (3 operations → 3 meaningful bins). Explicit bins (cp_size) — partition a numeric range into functionally-distinct cases: small (1–4), large (5–63), and max_size (64, the boundary carved out so it must be hit specifically, per Figure 1) — this is the art. Expression coverpoint (cp_align: coverpoint t.addr[1:0]) — measures a derived feature (the low two address bits → alignment), not a raw field — aligned (0) vs unaligned (1–3). Guarded coverpoint (cp_resp ... iff (t.valid)) — samples only when the value is meaningful (the response is valid), avoiding recording garbage when resp is don't-care. The anti-pattern (commented cp_addr: coverpoint t.addr on a 32-bit field) — auto bins over a wide variable → billions of meaningless bins (or auto_bin_max buckets of nonsense), never closes — don't. The shape to carry: a coverpoint is one variable (coverpoint t.<field> or an expression), and its bins — auto for small enums, explicit for ranges and boundaries, guarded with iff for conditional validity — define what "covered" means. The bins are the meaning: cp_size with the boundary carved out measures something different (and more) than cp_size with one coarse bin. The expression and guard features let coverpoints measure derived and conditional features — exactly the functionally-distinct cases the plan names. Each coverpoint measures one variable; its bins are where you encode what matters.

Verification Perspective — choosing the meaningful partition

The central skill of coverpoint design is choosing the partition — the boundary between a meaningful measurement and a useless one. Seeing the three partition regimes shows the art.

The figure shows the three partition regimes. Too fine (auto-bins on a wide 32-bit variable) → billions of bins (one per raw value) → the coverpoint never closes and measures nothing functional (you'd need to hit every value). Too coarse (one bin for the entire range) → 100% on the first sample → trivially covered, learning nothing (any value hits the one bin). Meaningful (a partition at the functionally-distinct seams — boundaries, ranges, special values) → covered only when each distinct case is exercised, so 100% actually means something. The verification insight is that the art is the middle partition — and both extremes fail in opposite ways that are both useless. The too-fine failure is obvious (coverage stuck near 0%, never closes); the too-coarse failure is insidious (coverage reads 100%, looks done, but means nothing — the false confidence of 19.1, now at the coverpoint level). The brand-colored meaningful partition is the goal: bins that carve the variable at the seams where behavior changes — the boundary (min/max, where off-by-one bugs live), the ranges that exercise different logic (small vs large transfers), the special values (aligned/unaligned, zero/nonzero, error/ok). When those bins are all hit, 100% means every functionally-distinct case was exercised — real completeness. The skill is asking: "what values of this variable behave differently in the design?" — and putting a bin at each. The diagram is the partition decision: too fine (never closes, measures nothing) and too coarse (trivial 100%, measures nothing) bracket the meaningful middle (bins at the seams, 100% means intent) — and coverpoint design is finding that middle. Partition where the design's behavior changes, not by raw value count.

Runtime / Execution Flow — a set of coverpoints encodes the plan

At run time, a covergroup's set of coverpoints together measure the transaction's features — each coverpoint one feature the plan names. The flow shows how the plan becomes coverpoints.

The flow shows how a set of coverpoints encodes the plan. Plan (step 1): the coverage plan lists the features — every operation, each size class and the boundary, each alignment, each response type — the scenarios to exercise (Module 19.1). Map (step 2): each feature becomes one coverpoint — cp_op, cp_size, cp_align, cp_resp — each measuring one variable with bins at its functionally-distinct cases. Sample (step 3): one cg.sample(t) captures every coverpoint's value at once — the transaction's features, all measured together. Read (step 4): the set of coverpoints is the plan, made executable — reading them tells you what the verifier decided matters, and their coverage is the plan's completeness. The runtime insight is that coverpoints are the executable form of the coverage plan: the plan is a list of features to exercise, and each feature is realized as one coverpoint with a meaningful partition. So building coverage is translating the plan into coverpoints — and reading the coverpoints (in code or in the coverage report) reconstructs the plan: "these are the features this team decided were worth measuring." This is why coverpoint design is a specification activity, not just coding: choosing which variables to measure and how to partition them is deciding what "thoroughly verified" means for this design. The set sampled together (one sample() records all coverpoints) reflects that they all describe the same transaction — op, size, align, resp are facets of one observed event. The flow is the plan-to-coverpoints translation: plan lists features → each becomes a coverpoint with meaningful bins → sampled together → the set is the executable plan. The coverpoints are where the plan stops being a document and becomes a measurement. Read a covergroup's coverpoints and you read the team's definition of "enough."

Waveform Perspective — values mapping to bins over time

A coverpoint is visible as values mapping to bins over successive samples: as the variable takes values, the matching bins get hit — and a bin never reached is a gap. The waveform shows range bins filling and a boundary bin left empty.

The waveform shows values mapping to bins over samples. The size variable takes values 3, 30, 7 on successive sampled transactions. The coverpoint cp_size maps each into its bin: size=3 hits small (1–4), size=30 and size=7 both hit large (5–63). The bins small and large fill — but max_size (the boundary, value 64) is never reached, so it stays empty: a coverage gap. The crucial reading is two-fold. First, each sampled value maps to exactly one bin — the coverpoint records size=3 → small, size=30 → large — demonstrating the value-to-bin mapping that is the coverpoint's operation. Second, size=7 and size=30 both hit large — a range bin is hit by any value in its range, so hitting large once covers it regardless of which large value occurred. This is exactly why carving the boundary into its own bin matters: if max_size were folded into large (a bin covering 5–64), then size=7 would read large hit and the coverpoint could reach 100% without ever exercising size=64 — the boundary bug would escape (the false 100% of Figure 2). By separating max_size, the coverpoint stays uncovered (the gap is visible, b_max empty) until size=64 is specifically exercised. The picture to carry is that a coverpoint fills its bins as values land in them, a range bin is satisfied by any value in range, and an unreached bin (the boundary, here) is a visible gap that keeps the coverpoint honest. Reading the waveform this way — which bins filled, which value mapped where, which bin is still empty? — is reading the coverpoint's progress. The small and large filling while max_size stays empty is the signature of a well-partitioned coverpoint doing its job: it refuses to read 100% until the boundary — the case that matters — is exercised. A range bin is hit by any value in range; carve the boundary out so it must be hit on its own.

DebugLab — the coverpoint at 100% that missed the boundary bug

✗ TOO-COARSE partition — one bin for the whole range:
  cp_size: coverpoint t.size { bins all = {[1:64]}; }
  // ANY size (1, 7, 64...) hits the single bin → 100% after the FIRST transaction
  // reads "fully covered" forever — but NEVER requires size==64 (the boundary) specifically
  // → off-by-one bug at size==64 escapes a 100%-covered coverpoint (FALSE confidence)
 
✓ MEANINGFUL partition — carve the functionally-distinct cases, especially the boundary:
  cp_size: coverpoint t.size {
    bins min      = {1};        // minimum boundary
    bins mid      = {[2:63]};   // the bulk range
    bins max_size = {64};       // MAXIMUM boundary — must be hit specifically
  }
  // now 100% REQUIRES size==1 AND size==64 to be exercised → the boundary is a tracked gap
  // until size==64 occurs, max_size stays empty → coverage < 100% → the bug's scenario is flagged

Common Mistakes

• Auto-bins on a wide variable. A 32-bit field auto-binned creates billions of meaningless bins that never close; partition it into functionally-distinct cases.
• One coarse bin for a whole range. Any value hits it, so it reads 100% trivially while never requiring the boundaries — carve the corners into their own bins.
• Folding the boundary into a range bin. A boundary (min/max) hidden in a range bin is never required specifically; give it a dedicated bin.
• Sampling a value that's only valid under a condition. Without an iff guard, a coverpoint records garbage when the field is don't-care; guard it with the validity condition.
• Measuring raw fields instead of derived features. Use expression coverpoints (e.g. addr[1:0] for alignment) to measure the functionally-distinct feature, not the raw value.
• Treating 100% as done without checking what it requires. A coverpoint at 100% is only meaningful if its bins require the corners; review the partition, not just the percentage.

Senior Design Review Notes

Interview Insights

Exercises

1. Partition a field. For an 8-bit length field where 0, 1, and 255 behave specially, write the coverpoint bins that make 100% require exercising those cases.
2. Spot the false 100%. Given coverpoint t.size with one bin for the whole range, explain why 100% is meaningless and how to fix it.
3. Derive a feature. Write an expression coverpoint that measures whether an address is aligned, without binning the raw address.
4. Guard a coverpoint. Explain when a response coverpoint needs an iff guard and what goes wrong without it.

Summary

• A coverpoint measures a single variable or expression by partitioning its value space into bins and recording which bins were hit — the atom of functional coverage (one coverpoint = one feature), with coverage = the fraction of its bins hit.
• Each sample of the covergroup captures every coverpoint's current value and records it into the matching bin; a range bin is hit by any value in its range, so the coverpoint is covered only when every bin is hit.
• The art is the partition: bins at the functionally-distinct seams — boundaries (min/max), meaningful ranges (small/large), special values (aligned/unaligned, error/ok) — not auto-bins on a wide variable (never closes, measures nothing) and not one coarse bin (trivial 100%, measures nothing).
• Coverpoints can measure derived features (expression coverpoints, e.g. addr[1:0] for alignment) and be guarded (iff — sample only when valid); a set of coverpoints is the coverage plan's features, made executable.
• The durable rule of thumb: a coverpoint is only as meaningful as its bins — partition the variable at its functionally-distinct seams and carve the boundaries and special values into their own bins, so that 100% coverage actually means the important cases were exercised, not merely that some value occurred; auto-bins on a wide field never close and one coarse bin is a false 100%, so always ask what 100% on this coverpoint actually requires.

Next — Coverage Bins: the next layer of detail — bins themselves: automatic versus explicit bins, value and range and wildcard bins, transition bins (value sequences), illegal and ignore bins, and how the bin definitions precisely control what each coverpoint requires and excludes.