AMBA AHB · Module 17

AHB Functional Coverage

Defining functional coverage for AHB — measuring which scenarios the testing actually exercised (not checking correctness). Coverpoints sampled per transaction: direction, HTRANS, HBURST, HSIZE, HRESP, and wait states; plus cross coverage (burst x size, direction x response). Coverage measures, it doesn't check — holes mean untested scenarios where the assertions and scoreboard never had a chance. Sign-off needs both: all checks pass AND coverage complete; a passing test with coverage holes is hollow, and high coverage with weak checks proves nothing. Coverage closure (find holes, add stimulus) drives constrained-random generation.

Assertions (17.2) and the scoreboard (17.4) check correctness — but they only catch a bug if the stimulus creates the scenario that triggers it. Functional coverage answers the other question: did we actually exercise the scenarios? It measures — it does not check. A coverage model is built from coverpoints (the interesting variables to track) and cross coverage (their combinations), sampled on each transaction from the monitor (17.3). The key AHB coverpoints, drawn straight from the protocol's variety: direction (read/write), HTRANS (IDLE/BUSY/NONSEQ/SEQ), HBURST (SINGLE, the INCR variants, the WRAP variants), HSIZE (byte through the bus width), HRESP (OKAY/ERROR), and wait states (0/1/many). The cross coverage combines them to find interesting combinations — burst × size (every burst at every size), direction × response (a read-with-error, a write-with-error). The crucial distinction is coverage vs checking: checking asks "did anything go wrong?"; coverage asks "did we exercise the scenario?". A passing test with poor coverage is hollow — the checks may pass only because the hard cases were never tried (an assertion that never fires might just have never armed). So sign-off needs both: all checks pass and coverage complete. Coverage closure is the process of adding stimulus until the holes fill. This chapter builds the coverage model.

1. What Is It?

AHB functional coverage is a model that measures which protocol scenarios were exercised. Its parts:

Coverpoints — the interesting variables tracked per transaction: direction, HTRANS, HBURST, HSIZE, HRESP, wait states.
Cross coverage — combinations of coverpoints (burst × size, direction × response) — the interesting interactions.
Sampled per transaction — the coverage is sampled on each transaction from the monitor (subscribing, like the scoreboard).
Measures, not checks — coverage reports which bins were hit; holes = untested scenarios (the checks never had a chance).

Figure 1 — an AHB functional coverage model. Coverpoints sampled per transaction: direction (READ/WRITE — 2 bins), HTRANS (IDLE/BUSY/NONSEQ/SEQ — 4 bins), HBURST (SINGLE, INCR, WRAP4/8/16, INCR4/8/16), HSIZE (byte/halfword/word up to bus width), HRESP (OKAY/ERROR — 2 bins), and wait states (0/1/2+/many — latency buckets). Cross coverage combines them: HBURST × HSIZE (every burst at every size), direction × HRESP (read-with-error, write-with-error). Coverage doesn't check — it reports which bins were hit; holes mean untested scenarios where the checks never had a chance.

So AHB functional coverage is the completeness measure of verification. The checkers (assertions, scoreboard) verify correctness — but only where the stimulus goes. Coverage measures where the stimulus went — which transfer types, bursts, sizes, responses, and corners were actually exercised. The coverpoints are the protocol's interesting axes of variety (the things that could expose a bug if combined the wrong way), and the crosses are the interactions (a bug might only appear for, say, a WRAP16 at byte size, or a write that gets an error). Coverage bins are hit when a transaction matches — and holes (unhit bins) reveal untested scenarios. The fundamental point: coverage measures, it doesn't check — it tells you what was tried, not what was correct. A test that passes all checks but has coverage holes is hollow: the checks passed, but only on the cases that were tried — the untested cases could still be buggy. So coverage is the completeness gauge that makes a passing result meaningful. So AHB functional coverage is the measure of what was exercised. So it's how you know verification is complete.

Functional coverage = coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, wait states) + cross coverage (burst×size, direction×response), sampled per transaction; it MEASURES what was exercised (doesn't check). Holes = untested scenarios; sign-off needs all-checks-pass AND coverage-complete

AHB functional coverage in one frame: a model that measures which protocol scenarios the testing actually exercised — built from coverpoints and cross coverage, sampled per transaction (from the monitor). The coverpoints track the protocol's interesting variety: direction (read/write), HTRANS (IDLE/BUSY/NONSEQ/SEQ), HBURST (SINGLE, INCR/INCR4/8/16, WRAP4/8/16), HSIZE (byte..bus-width), HRESP (OKAY/ERROR), wait states (0/1/2+/many). The cross coverage combines them for interesting interactions: burst × size (every burst at every size), direction × response (read-with-error, write-with-error). Each bin is hit when a transaction matches; holes (unhit bins) reveal untested scenarios. The crucial distinction: coverage measures, it does NOT check — checking (assertions/scoreboard) asks "did anything go wrong?"; coverage asks "did we exercise the scenario?". A passing test with coverage holes is hollow — the checks may pass only because the hard cases were never tried (an assertion that never fires might just have never armed — recall the vacuity guard from 17.2). So sign-off requires both: all checks pass AND coverage complete (every interesting scenario exercised and checked). Coverage closure is the iterative process of adding/tuning stimulus until the holes fill — the driver of constrained-random generation (17.6).

2. Why Does It Exist?

Functional coverage exists because checking alone is insufficient — checks only catch bugs in scenarios the stimulus reaches, so without measuring what was exercised, a passing result is meaningless (the checks might have never seen the buggy case); coverage quantifies completeness and drives stimulus to the unexercised corners.

The passing checks can be hollow is the root: a checker (assertion/scoreboard) only fires if the stimulus creates the triggering scenario. So if the stimulus never exercises a scenario (say, never inserts a wait state), the relevant check never runs — and the test passes, but not because the design is correct there; because it was never tested there. So a passing result, alone, is not evidence of correctness — it could be a hollow pass. So you need to know what was exercised. So coverage exists to expose the hollow pass — measuring what was actually tried. So it's the completeness check. So passing-alone is insufficient.

The quantify completeness drives the measurement: verification needs a quantitative answer to "how complete is our testing?". Coverage provides it — a percentage of bins hit, a list of holes. So instead of a vague "we tested a lot", you have a concrete "97% coverage, holes in WRAP16-with-error". So coverage exists to quantify completeness — making it measurable and trackable. So it's the metric. So quantification needs coverage.

The drive stimulus to the corners is the practical use: coverage holes direct the verification effort — they tell you exactly which scenarios need more stimulus. So you close coverage by writing/tuning tests (or constrained-random constraints — 17.6) to hit the holes. So coverage drives the stimulus generation toward completeness. So coverage exists to guide the testing to the unexercised corners. So it's the closure driver. So coverage exists because: checking alone is insufficient (a passing test can be hollow — checks never saw the buggy case — the why); it quantifies completeness (a concrete metric and hole-list — the measurement); and it drives stimulus to the unexercised corners (coverage closure — the guidance). So AHB functional coverage is the completeness measure that makes a passing result meaningful (every interesting scenario exercised and checked) and directs the verification effort to the holes — the partner to checking that together deliver sign-off. So this chapter builds the measure. So measure completeness, drive to the corners.

3. Mental Model

Model functional coverage as a restaurant's checklist of every dish the new chef must successfully cook before opening night — not a taste test, but a coverage of the menu. The taste test (checking) confirms each dish they do cook is good. But if the chef never cooked the soufflé, "every dish I made was tasty" is hollow — the hard dish was never attempted. The checklist tracks which dishes have been made (the bins hit), reveals the holes (the soufflé, untried), and isn't satisfied until every dish has been cooked and tasted. Opening night requires both: everything tasted good and the whole menu was attempted.

A restaurant preparing a new chef (the design) for opening night (sign-off). There are two distinct activities. The taste test (the checking — assertions/scoreboard): every dish the chef cooks is tasted to confirm it's good. If a dish is bad, the taster catches it. But the taste test only evaluates the dishes the chef actually cooks. So there's a second activity: a menu checklist (the coverage) tracking which dishes have been cooked at all. Here's the trap: suppose the chef only ever cooks the easy dishes — the salad, the pasta — and never attempts the soufflé (the hard corner). The taste test reports "every dish was delicious!" — all passes. But that's hollow: the soufflé was never made, so we have no idea if the chef can cook it. The taste test passing is not evidence the chef is ready — it's evidence the dishes they tried were fine. The menu checklist exposes this: it shows the soufflé box is unchecked (a coverage hole) — that dish was never attempted. So the checklist reveals the gap the taste test can't. And opening night requires both: every dish tasted good (all checks pass) and every dish on the menu attempted (coverage complete). If the soufflé is unchecked, you're not ready — you send the chef back to cook the soufflé (add stimulus to hit the hole), then taste it (check it). You iterate — cooking the missing dishes — until the whole menu is cooked and tasted (coverage closure). And crucially, the checklist doesn't taste — it only tracks what was made; the tasting is a separate job. So you measure the menu coverage and check each dish, and you're ready only when both are complete.

This captures functional coverage: the taste test confirming each dish is good = checking (assertions/scoreboard — correctness); the menu checklist of dishes attempted = the coverage model (completeness); the chef only cooking easy dishes = stimulus only exercising easy scenarios; "every dish was delicious" being hollow = a passing test with coverage holes; the unchecked soufflé box = a coverage hole (untested scenario); the checklist exposing the gap = coverage revealing what checking can't; sending the chef back to cook the soufflé = adding stimulus to hit the hole; iterating until the whole menu is done = coverage closure; the checklist not tasting = coverage measuring, not checking; opening night needing both = sign-off requiring all-checks-pass AND coverage-complete. Track what was attempted, taste each one, and open only when the whole menu is cooked and tasted.

Watch coverage expose a hollow pass:

Coverage exposes a hollow pass

3 cycles

Figure 2 — coverage exposes a hollow pass. A test run drives only zero-wait, SINGLE, word transfers with OKAY responses. The 'checks' row shows all PASS — no assertion or scoreboard error. But the 'coverage' rows reveal the truth: the wait-states coverpoint hit only the '0' bin (1+ never hit), HBURST hit only SINGLE (INCR/WRAP never hit), HRESP hit only OKAY (ERROR never hit). So the passing result is hollow: the wait-state, burst, and error scenarios were never exercised — the checks for them never had a chance to fire. Coverage shows the holes; checking alone would have falsely suggested completeness. Sign-off requires filling these holes (more stimulus) and re-checking.

The model's lesson: track what was attempted, taste each one, and open only when the whole menu is cooked and tasted. In the figure, all checks pass — but the coverage holes (no waits, no bursts, no errors) reveal the pass is hollow: the hard scenarios were never exercised, so the checks for them never ran.

4. Real Hardware Perspective

In SystemVerilog, functional coverage is a covergroup with coverpoints (and bins), cross coverage, sampled on each transaction (often in the monitor or a subscriber); the bins define the interesting values, and the coverage report shows the holes.

The covergroup and coverpoints: a covergroup groups the coverpoints and is sampled (e.g. cg.sample(txn) on each monitor transaction). Each coverpoint tracks a variable with bins: coverpoint txn.htrans { bins idle = {IDLE}; bins busy = {BUSY}; bins nonseq = {NONSEQ}; bins seq = {SEQ}; }. The bins define which values count. So in SV, the coverage is a sampled covergroup of binned coverpoints. So it's structured. So that's the form.

Figure 3 — coverage measures, checks verify — and you need both. Checking (assertions + scoreboard) asks 'did anything go wrong?' — catching protocol violations and data mismatches; but passing isn't correct if scenarios are untested (an assertion that never fires may just never have armed). Coverage asks 'did we exercise the scenario?' — measuring which bins were hit; holes mean untested scenarios where the checks never had a chance, exposing the hollow pass (e.g. the wait-state bin never hit). Sign-off = all checks pass AND coverage complete (every interesting scenario exercised and checked).

The cross coverage: a cross combines coverpoints: cross cp_burst, cp_size; — creating a bin for each combination (every burst at every size). Crosses multiply the bins, so you often exclude illegal/irrelevant combinations (ignore_bins) and focus on the meaningful ones. So in SV, crosses capture the interactions. So they're combinations. So that's the cross.

The sampling and the report: the covergroup is sampled per transaction (so it records what actually occurred — measuring, not driving). The simulator produces a coverage report — percentage hit, which bins are holes. The verification team reviews the report, identifies holes, and adds stimulus (or constraints — 17.6) to fill them — iterating to closure. So in SV, functional coverage is a sampled covergroup (coverpoints + bins + crosses) producing a coverage report that drives closure. The skill is choosing the right coverpoints/bins/crosses (the interesting scenarios — not everything, which is noise) and closing the holes. So in SV, build a focused covergroup and close the holes. So that's the implementation.

5. System Architecture Perspective

At the system level, functional coverage is the sign-off metric — the quantitative answer to "are we done?" — the driver of the constrained-random verification loop, and the bridge between what the spec requires and what was tested.

The sign-off metric: coverage is the metric for verification completeness — "are we done testing?" is answered by "is coverage closed?" (every interesting bin hit and all checks pass). So at the system level, coverage is the sign-off gate — you don't ship until coverage is closed. So it's the done-criterion. So coverage gates sign-off.

The closure loop driver: coverage drives the verification loop: run stimulus → measure coverage → find holes → add/tune stimulus (constrained-random — 17.6) → re-measure → repeat until closed. So coverage is the feedback that steers the testing toward completeness. So at the system level, coverage is the engine of the constrained-random methodology. So it's the loop driver. So coverage steers the effort.

The spec-to-test bridge: coverage is where the spec's requirements become testing targets. The spec defines the protocol's variety (all the burst types, sizes, responses); the coverage model encodes that variety as coverpoints; closing coverage proves the variety was tested. So coverage connects "what the spec requires" to "what was tested" — a traceable link. So at the system level, functional coverage is the sign-off metric (the quantitative "are we done?" — gating ship), the driver of the closure loop (measure → find holes → add stimulus → repeat — steering the constrained-random methodology — 17.6), and the spec-to-test bridge (encoding the spec's required variety as coverage targets — traceable). So functional coverage is what turns verification from "we ran a lot of tests" into "we measurably exercised and checked every required scenario" — the completeness backbone of a sign-off-quality verification. So measure coverage, close the holes, and ship only when complete. So coverage is the done-gauge.

6. Engineering Tradeoffs

AHB functional coverage embodies the measure-completeness, focused-coverpoints, drive-closure design.

Coverage (measure) vs checking (verify). Coverage measures what was exercised; checking verifies correctness. They're different — use both (a passing test with holes is hollow). Neither replaces the other.
Focused coverpoints vs cover-everything. Focused coverpoints (the interesting variety + meaningful crosses) give signal; covering everything (every signal, every combination) is noise and unclosable. Choose the interesting scenarios.
Cross coverage vs single coverpoints. Crosses find interaction bugs (burst × size) but multiply bins (harder to close); single coverpoints are easier but miss interactions. Cross the interacting axes; ignore_bins the irrelevant.
Closure via constrained-random vs directed. Constrained-random (17.6) fills most coverage automatically (efficient for the bulk); directed tests target the stubborn holes. Use random for breadth, directed for the last holes.

The throughline: AHB functional coverage measures which protocol scenarios were exercised — a covergroup of coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, wait states) and cross coverage (burst × size, direction × response), sampled per transaction from the monitor. It measures, it does NOT check — holes (unhit bins) reveal untested scenarios where the checks never had a chance. The crucial distinction: checking (assertions/scoreboard) asks "did anything go wrong?"; coverage asks "did we exercise it?" — and a passing test with coverage holes is hollow. Sign-off needs both: all checks pass AND coverage complete. Coverage closure (measure → find holes → add stimulus → repeat) drives the constrained-random loop (17.6). It's the sign-off metric, the closure-loop driver, and the spec-to-test bridge — the completeness backbone.

Coverage MEASURES, it does NOT check — a high coverage number with passing checks is only meaningful if the coverage is on the RIGHT scenarios. Don't confuse the two: 100% coverage with weak checks proves nothing, and passing checks with coverage holes proves nothing. You need strong checks AND complete coverage on interesting scenarios

The central confusion to avoid is conflating coverage with checking — and the two failure modes are symmetric and both leave you with false confidence. (1) Coverage without checking (100% coverage, weak checks → proves nothing). Coverage only measures what was exercised — it does not verify correctness. So you could exercise every scenario (100% coverage) and still ship bugs if your checks are weak (or vacuous — 17.2). A high coverage number with inadequate assertions/scoreboard is meaningless — you drove all the scenarios but didn't check whether they were correct. Coverage is necessary but not sufficient; checking is what finds the bugs. (2) Checking without coverage (passing checks, coverage holes → proves nothing). Conversely, strong checks that pass prove nothing if the stimulus never exercised the hard scenarios — the hollow pass. An assertion that never fires might be vacuous (never armed — 17.2), and a scoreboard that never mismatches might never have seen the corner. So passing checks with coverage holes means the untested scenarios could still be buggy — the checks just never ran there. The resolution: you need both, and the coverage must be on the RIGHT (interesting) scenarios. Strong checks (real assertions, an attribute-aware independent scoreboard — 17.2/17.4) plus complete coverage (every interesting scenario exercised) — together — give sign-off-quality assurance: every interesting scenario was exercised AND checked. The further subtlety: coverage must be meaningful — 100% coverage of trivial bins (e.g. only "a transfer happened") proves little; coverage of the interesting variety and interactions (the bursts, sizes, errors, waits, and their crosses) is what matters. And the two interlock: coverage tells you where the checks ran (closing holes ensures the checks saw every scenario), and checks tell you whether those scenarios were correct. So never report "we hit 99% coverage" as if it meant "the design is correct" (it means exercised, not correct), and never report "all checks pass" as if it meant "we tested everything" (check the coverage). The discipline: strong checks AND complete, meaningful coverage — measured separately, required together. (See AHB Assertions (SVA) for the vacuity link and AHB Scoreboards for the checking side.)

7. Industry Example

Define and close functional coverage for the register-bank/memory verification, exposing and filling holes.

You're verifying the 16.x slaves. You add a coverage model and use it to drive the testing to completeness.

The coverpoints. cp_dir (read/write), cp_htrans (IDLE/BUSY/NONSEQ/SEQ), cp_burst (SINGLE/INCR/WRAP4/8/16/INCR4/8/16), cp_size (byte/halfword/word), cp_resp (OKAY/ERROR), cp_wait (0/1/2+/many) — sampled on each monitor transaction.
The crosses. cp_burst × cp_size (every burst at every size — to find a burst that mishandles a particular size), cp_dir × cp_resp (read-with-error and write-with-error — to ensure both error directions are tested).
First run — holes exposed. The initial directed tests drive only zero-wait, SINGLE, word, OKAY traffic. The coverage report shows all checks pass but huge holes: cp_wait only hit 0; cp_burst only hit SINGLE; cp_resp only hit OKAY; the crosses mostly empty. The passing result is hollow — waits, bursts, and errors were never exercised.
Closing the holes. You add stimulus (constrained-random — 17.6) to hit the holes: random wait states (fills cp_wait), all burst types (fills cp_burst), error injection (fills cp_resp ERROR and the cp_dir × cp_resp crosses), all sizes (fills cp_size and the cp_burst × cp_size cross).
A bug found via closure. Driving the WRAP16 × byte cross (previously a hole) exercises the burst-address-wrap logic at byte granularity — and the scoreboard catches a wrong wrap (a boundary-wrapping bug — 8.8) that the zero-wait/SINGLE/word tests never reached. Closing the coverage hole is what exposed the bug.
Sign-off. When all coverpoints/crosses are hit (coverage closed) and all checks pass, the verification is complete — every interesting scenario exercised and checked.

The example shows coverage driving completeness: the holes revealed the hollow initial pass, guided the stimulus to the unexercised corners, and closing a hole (WRAP16 × byte) exposed a real bug the checks would catch but never reached. Coverage + checking together delivered sign-off. This is how you know you're done. This is the completeness backbone.

8. Common Mistakes

AHB-coverage misconceptions

"High coverage means the design is correct." No — coverage measures what was exercised, not correctness. 100% coverage with weak checks proves nothing. Need strong checks too.
"Passing checks mean we tested everything." No — a passing test with coverage holes is hollow (the hard cases were never tried). Check the coverage.
"Cover everything (every signal, every combination)." No — that's noise and unclosable. Cover the interesting variety and meaningful crosses; ignore_bins the irrelevant.
"Coverage checks correctness." No — coverage only measures; checking (assertions/scoreboard) verifies correctness. They're different and complementary.
"Trivial coverage is fine." No — 100% of trivial bins ("a transfer happened") proves little. Coverage of the interesting scenarios and interactions is what matters.
"Coverage and stimulus are unrelated." No — coverage drives stimulus: holes tell you what to generate (the constrained-random closure loop — 17.6).

9. Interview Insight

Functional coverage is a core verification interview topic — the measure-not-check distinction, the coverpoint/cross design, and the coverage-closure + both-needed framing are the signals.

Figure 4 — a strong answer in one card: coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, wait states) + cross coverage (burst × size, direction × response), sampled per transaction; coverage measures, doesn't check (holes = untested scenarios); sign-off = all checks pass AND coverage complete; closure = add stimulus until holes fill. The senior point: coverage measures completeness, not correctness — a passing test with coverage holes proves little.

The answer that lands gives the measure-not-check distinction and the coverpoints: "Functional coverage measures which interesting scenarios the testing actually exercised — it does not check correctness, it measures completeness. I'd build a covergroup sampled on each transaction from the monitor, with coverpoints for the protocol's interesting variety: direction, read or write; HTRANS — IDLE, BUSY, NONSEQ, SEQ; HBURST — SINGLE and the INCR and WRAP variants; HSIZE — byte up through the bus width; HRESP — OKAY and ERROR; and wait states, bucketed as zero, one, and many. Then cross coverage for the interactions: burst crossed with size, to make sure every burst type runs at every size, and direction crossed with response, to ensure both a read-with-error and a write-with-error are tested. The crucial thing is that coverage measures, it doesn't check. Checking — assertions and the scoreboard — asks 'did anything go wrong?'; coverage asks 'did we exercise the scenario?'. These are different and both necessary. A passing test with coverage holes is hollow, because the checks may have passed only because the hard cases were never tried — an assertion that never fires might just never have armed. So sign-off requires both: all checks pass and coverage is complete. Coverage closure is the iterative process — run stimulus, measure coverage, find the holes, add or tune stimulus to fill them, repeat — and that's what drives constrained-random generation. The two failure modes I watch for are: high coverage with weak checks, which proves nothing because you exercised scenarios but didn't verify them; and passing checks with coverage holes, which proves nothing because the untested scenarios could still be buggy. You need strong checks and complete, meaningful coverage on the interesting scenarios, together." The measure-not-check distinction, the coverpoint/cross design, and the closure + both-needed framing are the senior signals.

🔍 The discriminator: coverage MEASURES completeness, not correctness — and checking VERIFIES correctness, not completeness; a passing test with coverage holes is hollow, and high coverage with weak checks proves nothing. Sign-off needs strong checks AND complete, meaningful coverage

The discriminator on functional coverage is whether you cleanly separate coverage (measures completeness) from checking (verifies correctness) and grasp that both are required. A weak answer says "I'd add coverage to measure how much I tested." A solid answer lists the coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, waits) and crosses (burst × size, direction × response). But the senior answer nails the measure-vs-check distinction and its two symmetric failure modes: (1) coverage without strong checking — 100% coverage with weak/vacuous checks (17.2) proves nothing (you exercised the scenarios but didn't verify them — coverage is necessary, not sufficient); (2) checking without coverage — passing checks with coverage holes is a hollow pass (the checks never ran on the untested corners — an assertion that never fires might be vacuous). The resolution is the signal: sign-off requires both — strong checks (real assertions + an independent attribute-aware scoreboard — 17.2/17.4) AND complete, meaningful coverage (every interesting scenario exercised). The standout nuances: (a) coverage must be meaningful — 100% of trivial bins ("a transfer happened") proves little; cover the interesting variety and interactions; (b) coverage drives the closure loop — measure → find holes → add stimulus (constrained-random — 17.6) → repeat — and closing a hole often exposes a real bug (the corner the checks would catch but never reached); (c) coverage is the sign-off metric (the quantitative "are we done?") and the spec-to-test bridge (the spec's required variety → coverage targets). The killer framing: coverage tells you where the checks ran; checks tell you whether it was correct — they interlock. A candidate who never conflates the two, names both failure modes, and frames sign-off as strong-checks-AND-complete-coverage demonstrates real verification-methodology maturity — not just "write a covergroup".

10. Practice Challenge

Build and reason from AHB functional coverage.

The model. Describe the coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, wait states) and crosses (burst × size, direction × response).
Measure not check. Explain how coverage measures completeness (not correctness) and how it complements checking.
Read the waveform. From Figure 2, explain how coverage exposes a hollow pass (checks pass, but waits/bursts/errors are holes).
Two failure modes. Explain why high coverage with weak checks proves nothing, and passing checks with coverage holes proves nothing.
Closure. Describe the coverage-closure loop and how closing a hole can expose a real bug.

11. Key Takeaways

Functional coverage measures what was exercised — a covergroup of coverpoints (direction, HTRANS, HBURST, HSIZE, HRESP, wait states) and crosses (burst × size, direction × response), sampled per transaction.
Coverage measures, it does NOT check — holes (unhit bins) reveal untested scenarios where the checks never had a chance. Checking (assertions/scoreboard) verifies correctness.
A passing test with coverage holes is hollow — the checks may pass only because the hard cases were never tried (recall vacuous assertions — 17.2).
Sign-off needs both — all checks pass AND coverage complete (every interesting scenario exercised and checked). Two symmetric failure modes: high coverage + weak checks, and passing checks + coverage holes — both prove nothing.
Coverage must be meaningful — 100% of trivial bins proves little; cover the interesting variety and interactions. Use ignore_bins for irrelevant combinations.
Coverage drives closure — measure → find holes → add stimulus (constrained-random — 17.6) → repeat; closing a hole often exposes a real bug. It's the sign-off metric, the closure-loop driver, and the spec-to-test bridge.

12. What Comes Next

You now can measure verification completeness. The next chapter generates the stimulus that fills the coverage:

Constrained-Random AHB Traffic (next) — generate legal, stressful random AHB stimulus (driven by coverage closure).
Wait-State / Burst / Error-Response Testing, and the UVM AHB Agent — targeted tests and the assembled VIP.

To revisit what coverage complements, see AHB Assertions (SVA) and AHB Scoreboards; for the transactions it samples, see AHB Monitors.