Coverage-Driven Verification

Verification Foundations · Module 1 · Page 1.8

The Engineering Problem

The previous lesson left a hole in the methodology, literally. Constrained-random gives you breadth — millions of legal transactions — but a damning question remained: what did all those cycles actually exercise? A 50-million-cycle regression that silently excluded the zero-length corner looked identical to a thorough one. Cycle count is effort, not reach, and breadth you cannot measure is breadth you cannot trust.

Coverage is the answer to that question, and it reframes the entire activity. Without it, verification has no definition of done — you stop when the schedule ends, which is not an engineering criterion. With it, "done" becomes a measurable statement: the scenarios that matter were exercised.

But coverage carries its own trap, and it is the single most important idea in this lesson:

Coverage measures whether a scenario happened — never whether the design responded correctly. It tells you where you have looked, not whether what you saw was right.

So the engineering problem is two-sided: build a coverage model that honestly measures reach, and never mistake that measurement for a measure of correctness.

Motivation — why coverage is the linchpin of the whole flow

Every methodology so far produced something; only coverage measures something. That is why it sits at the center of the modern flow:

• It defines "done." Without coverage, sign-off is "the deadline arrived." With a coverage model, sign-off is a statement: the high-risk bins are closed. One is a calendar; the other is engineering.
• It makes constrained-random accountable. Random's breadth is meaningless until you can say what it hit. Coverage is the map that turns "we ran a lot of cycles" into "we exercised these scenarios and not those" — and the empty bins are the unreached corners.
• It steers effort to where risk remains. A zero-hit bin on a high-risk corner is a precise instruction: spend a directed test or a tighter constraint there, not on the easy states the solver already pounds. Coverage turns a brute-force engine into a directed search.
• It exposes over-constraint and dead code alike. The empty zero-length bin from the previous lesson would have screamed on day one; an always-false branch in code coverage flags logic that nothing can reach. Coverage finds the gaps in both your stimulus and your design.

The motivation is singular: coverage is the only methodology that turns the others into a closed loop. It is how breadth becomes accountable, how random becomes directed, and how "enough" becomes a number instead of a feeling.

Mental Model

Hold this picture:

Coverage is the map of where verification has been — and a map is not the territory. You draw the map yourself: each coverpoint is a question ("which burst lengths occurred?"), each bin is a place on the map ("zero", "small", "large"), and a cross asks whether two questions were answered together ("did each length occur with each burst type?"). As stimulus runs, the map fills in. Closure is the map fully coloured for the regions that matter. But the map only shows where you went — it says nothing about whether the design behaved correctly when you got there. That verdict belongs to a separate instrument: the checker.

Two families of map exist. Code coverage is drawn automatically from the RTL — did each line, branch, toggle, and FSM state get exercised? It answers "did the structure run?" Functional coverage is drawn by hand from the spec — did each intended scenario happen? It answers "did the behaviour occur?" You need both, and neither measures correctness.

Visual Explanation — the layers of coverage

Coverage is not one thing. It is a progression from automatic structural measurement to hand-authored intent, ending in the only definition of "done" that means anything.

The progression carries the argument. Code coverage is free but shallow — 100% of it means every line ran, not that every behaviour was exercised or correct (a line can execute in only its boring case). Functional coverage is expensive but meaningful — you author it from the spec, so it measures the scenarios you actually care about. Cross coverage is where the interaction corners live — the very combinations constrained-random was built to reach. And closure is the payoff: a defensible, quantified statement of "done." None of the four says anything about whether an output was correct.

RTL / Simulation Perspective — a covergroup that defines "done"

Here is functional coverage in SystemVerilog: a covergroup with two coverpoints, each split into bins, and a cross that asks whether every length occurred with every burst type. It samples on an event — typically the moment a transaction is accepted.

class bus_cov;
  bit [7:0] len;
  bit [1:0] burst;                       // 00=FIXED, 01=INCR, 10=WRAP
 
  covergroup cg @(posedge sample_ev);    // sample when a transaction is accepted
    cp_len: coverpoint len {
      bins zero  = {0};                  // the legal boundary that bit us last lesson
      bins small = {[1:4]};
      bins large = {[5:16]};
    }
    cp_burst: coverpoint burst {
      bins fixed = {2'b00};
      bins incr  = {2'b01};
      bins wrap  = {2'b10};
    }
    x_len_burst: cross cp_len, cp_burst; // did each length occur with each burst?
  endgroup
 
  function new(); cg = new(); endfunction
endclass

Read what the model claims. cp_len asserts the interesting length regions are zero, small, and large — and the instant you write bins zero = {0}, the report will tell you whether zero-length transfers ever happened. That single bin is exactly what the previous lesson's over-constrained regression was missing: with this coverpoint in place, the zero bin would have read 0 hits across all 50 million cycles, exposing the excluded corner on the first run. The x_len_burst cross goes further, asking whether zero × wrap, large × fixed, and every other combination occurred — the interaction corners no single coverpoint can see. The covergroup is your honest, written-down definition of what "exercised" means.

Verification Perspective — coverage closes the loop, checking closes the deal

Coverage is only useful inside a loop. You run the broad random flow, measure what it hit, and spend targeted effort exactly where the map shows holes — then repeat until the regions that matter are coloured in.

This loop is the operational heart of coverage-driven verification, but note carefully what it does not contain: a correctness check. The loop drives stimulus toward unexercised scenarios; it never asks whether the DUT answered correctly in any of them. That is a separate instrument running in parallel — assertions for contracts, a scoreboard for end-to-end intent. Coverage and checking are orthogonal axes. A run can be 100% covered and entirely unchecked (you exercised everything, verified nothing) or fully checked but barely covered (everything you looked at was right, but you barely looked). Real sign-off requires both axes high: the scenarios happened and every one of them passed its check.

Waveform Perspective — sampling fills the bins

Coverage is collected by sampling a value at an event. Here a transaction's len is sampled each time a handshake completes, and each sampled value falls into a bin — the act of filling the map, made concrete.

The waveform shows the two subtle ways sampling decides what coverage means. First, when you sample: the covergroup fires on the handshake (valid && ready), so it records the value that was actually transferred — sampling a cycle early or late, or when valid is low, would log garbage and quietly corrupt every bin. Second, what stays empty: the zero bin gets no hits in this window, and that emptiness is the finding — coverage's value is as much in the bins that don't fill as in the ones that do.

DebugLab — 100% coverage, signed off, shipped a data-corruption bug

functional coverage:   100%   ← every scenario was EXERCISED
scoreboard / checker:  off    ← no scenario was CHECKED
reported failures:     0      ← of course — nothing was comparing anything
the size-N corruption: hit many times, passed every time (unchecked)

Common Mistakes

• Reading coverage as correctness. The cardinal error. Coverage measures reach — that a scenario happened — never that the design responded correctly. 100% coverage with a weak or disabled checker verifies nothing; the verdict is always the checker's.
• Trusting 100% code coverage as "done." Code coverage proves every line ran, not that every behaviour occurred or was correct — a line can execute only in its trivial case. Functional coverage (did the scenario happen?) is the relevant measure, and even it bounds known risk, not correctness.
• Sampling at the wrong moment. A covergroup that samples a cycle early/late, or while the transaction is invalid, records meaningless values and quietly corrupts every bin. Sample on the event that means "this value is real" (e.g. an accepted handshake).
• Ignoring empty bins. A zero-hit bin on a legal, high-risk corner is the single most valuable line in the report — it is an unexercised scenario (often an over-constraint, as in the previous lesson). The map's blank regions are the point, not an afterthought.
• Chasing 100% of everything. Not all bins carry equal risk, and the last fraction of a percent on low-risk or hard-to-reach bins can cost more than it is worth. Closure is about the bins that matter, with the rest explicitly justified — not a vanity number.
• No illegal/ignore bins. Failing to mark genuinely illegal value combinations as illegal_bins/ignore_bins either pollutes the denominator (unreachable bins you can never close) or lets a truly-illegal event pass silently. Model legality explicitly.

Senior Design Review Notes

Interview Insights

Exercises

1. Read the report. A functional-coverage report shows cp_len.zero = 0 hits after a 20-million-cycle constrained-random run, everything else green. State the three distinct causes this single line could indicate, and the next action for each.
2. Two axes. A teammate says "we're at 100% coverage with zero failures, let's tape out." Write the one experiment you would run before agreeing, and explain exactly what a passing vs failing result of that experiment would tell you.
3. Design the model. For the bus_txn of the previous lesson (addr, len, burst), write the covergroup you would author: name the coverpoints, the bins for each (including the boundary bins), the one cross that matters most, and which combination you would mark illegal_bins — and justify each choice in a sentence.
4. Sampling bug. A covergroup samples len on @(posedge clk) unconditionally rather than on the accepted handshake. Describe what the bins will record and why the resulting coverage is worse than useless, then give the corrected sampling event.

Summary

• Coverage answers the question constrained-random left open — what did we actually exercise? — and in doing so gives verification its only meaningful definition of "done": the high-risk bins are closed, not the calendar.
• It comes in two families: code coverage (automatic, structural — did the lines/branches/states run?) and functional coverage (authored from the spec via covergroups, coverpoints, bins, and crosses — did the intended scenarios and their combinations happen?). You need both; cross coverage is where the interaction corners live.
• Coverage runs as a closure loop: measure what random hit, drive targeted stimulus at the holes, repeat until the bins that matter are filled — turning brute-force random into a directed search, and exposing over-constraint via empty bins.
• The non-negotiable caveat: coverage measures reach, never correctness. It and checking are orthogonal axes — 100% coverage with a sleeping checker verifies nothing. Sign-off needs both high: the scenarios happened and every one passed its check.
• The durable rule of thumb: coverage tells you where you looked; a checker tells you whether what you saw was right — never confuse the map for the territory, and never sign off on one axis alone.

Next — Evolution Toward UVM: you now have the full methodology toolkit — directed, constrained-random, coverage, and the checks that judge them. The next lesson follows how engineers assembled these into reusable verification environments, and why that drive for reuse led, step by step, to UVM.