Your regression is green: ten thousand constrained-random tests, zero failures. Time to celebrate? Not yet — a green regression answers "did anything we tried fail?" and stays silent on the question that actually matters: what did we try? Ten thousand tests that all happened to be small aligned reads prove nothing about writes, or boundaries, or the read-after-write hazard. Functional coverage is the discipline that makes "have we tested it?" a measured quantity: you declare the scenarios that matter, the simulator counts how often each actually occurred, and the holes in the count are your to-do list. It is the difference between "we ran a lot of tests" and "we know what our tests did".

Covergroups, coverpoints, bins

The declaration mirrors the assertion machinery: you write what matters, the simulator tallies it. A covergroup samples signals at an event (usually a clock edge); each coverpoint watches one expression; its bins partition the values into the cases you care about:

Each bin is a little odometer: "how many times did a subtraction happen?", "how many times was an operand zero?". An illegal_bins is a tripwire — sampling it fails the test outright. And the cross is where the real power lives: it counts combinations — did we ever subtract from zero? AND with a big operand? Bugs overwhelmingly hide at the intersections of features ("the FIFO was full while an error arrived during a flush"), which no single coverpoint can see. Crossing an n-bin point with an m-bin point makes n \times m cross bins — the combinatorics that keeps verification teams honest and busy.

The closure loop

Coverage turns verification into a feedback loop with a name — coverage closure: run the regression; read the coverage report; find the holes (bins at zero); write or steer tests to hit them (new constraints, new directed tests, new seeds); repeat until every bin is hit or consciously waived. The curve it produces is one of the most recognisable shapes in the industry:

Random stimulus sprints through the easy scenarios — the first hundred tests buy more coverage than the next ten thousand — then stalls: some bins are simply too improbable to hit by luck (the FIFO-full-during-error cross might need a one-in-a-billion coincidence). Those last bins are hit by aiming: tightening constraints around the hole, or writing an old-fashioned directed test. The plateau is not failure; it is the report telling you where imagination must take over from dice.

Count the bins yourself

A coverage collector is honestly just a map of counters. Watch one discover a hole — and watch the hole persist until the stimulus is steered:

Five thousand aimless tests lose to two hundred aimed ones — the closure loop in miniature. The report told us which scenarios were missing; the fix was a constraint making zero operands likely; the holes closed.

Code coverage, functional coverage, and "done"

Tools also report code coverage for free: which RTL lines executed, which branches both ways, which signal bits toggled. It is necessary — an unexecuted line is untested by definition — but shallow: code coverage measures the design as written, not the intent. Every line of a FIFO can execute without ever testing "full and empty in the same microsecond" — a scenario, not a line. Functional coverage measures scenarios; code coverage catches the parts of the design your scenario list forgot even to mention. You need both, and neither is sufficient.

So when is verification done? Here is the uncomfortable truth this course will repeat at tape-out: it is never done — it is risk management. There is no proof at the end of simulation, only evidence: functional coverage closed, code coverage explained, regressions clean across thousands of seeds, assertions never vacuous, reviews signed. Tape-out is the day the accumulated evidence outweighs the cost of waiting — a judgement call wearing an engineering costume, made honest by the numbers this lesson taught you to collect.