Assertion / Coverage Synergy

Assertions in UVM · Module 21 · Page 21.5

The Engineering Problem

This module built the assertion layer — integrated (21.1), written (21.2), positioned as a methodology (21.3), and debugged (21.4). But a recurring thread has been unresolved: an assertion that passes in simulation might have checked nothing — a vacuous pass (21.1, 21.3, 21.4), where the antecedent never fired. A team that signs off the assertion suite on "all assertions passing, green" can ship a protocol bug that a critical assertion was written to catch — because that assertion passed vacuously, never exercised, never actually checking. The missing piece is measurement: how do you know an assertion actually fired its check, and not merely passed because its scenario never occurred? The answer unites this module with Module 19's coverage: assertion coverage — cover property — measures whether the assertion's scenario was exercised. The protocol layer has the same two orthogonal questions as the transaction layer (Module 19.1): correctness (do the rules hold? — assertions) and completeness (were the rules exercised? — assertion coverage). The problem this chapter solves is the synergy: how cover properties measure that assertions fired their checks, how assertion coverage feeds closure, how vacuous passes are coverage gaps, and how assertions and coverage together close the loop on both correctness and completeness of the protocol checking.

Assertion/coverage synergy is the union of the two orthogonal questions for the protocol/assertion layer: assertions check correctness (do the protocol rules hold?), and assertion coverage (cover property) checks completeness (were the rules actually exercised?). A cover property measures whether a sequence or antecedent occurred — answering "did this assertion actually check?". There are two kinds: antecedent coverage (cover property (req) — did the triggering condition occur, so the assertion ran, not vacuously?) and scenario coverage (cover property (req ##[1:3] ack) — did the full interesting protocol sequence occur?). Assertion coverage feeds the closure picture alongside functional and code coverage (Module 19.6/19.7) — a closed verification requires the assertions' antecedents/scenarios covered, proving the protocol checking was exercised. Crucially, a vacuous pass (21.4) is exactly an assertion-coverage gap — a 0-hit antecedent cover — detected systematically (not by hoping) and closed by the coverage-feedback loop (Module 20.4): steer stimulus to exercise the uncovered antecedent. So closing the assertion layer requires both: all assertions passing (correctness) AND all assertion coverage hit (completeness) — mirroring the scoreboard + functional coverage relationship for the signal/protocol layer. This chapter is the synergy: assertion coverage, its two kinds, feeding closure, vacuous-pass-as-gap, and closing the loop on correctness and completeness.

How do assertions and coverage unite — how does a cover property measure that an assertion actually fired its check, what are the two kinds of assertion coverage, why is a vacuous pass exactly an assertion-coverage gap, and how do assertions (correctness) and assertion coverage (completeness) together close the loop on the protocol checking?

Motivation — why passing assertions aren't enough

A passing assertion is necessary but not sufficient — the same lesson as passing tests (Module 19.1), now for the assertion layer. The reasons coverage must accompany assertions:

• A passing assertion might have checked nothing. A vacuous pass (antecedent never fired) reports green while verifying nothing. Without coverage, you can't tell a real pass (rule exercised and held) from a vacuous one (rule never exercised).
• Correctness and completeness are orthogonal — for assertions too. Assertions answer "do the rules hold?" (correctness); they say nothing about "were the rules exercised?" (completeness). The protocol layer needs both — exactly as the transaction layer needs scoreboard + functional coverage (19.1).
• Vacuous passes are detectable, not just feared. Assertion coverage (covering the antecedents) turns the vacuous-pass worry into a measurable gap: a 0-hit antecedent cover names the un-exercised assertion systematically.
• Assertion coverage is part of closure. A defensible closure (19.7) includes assertion coverage — proving the protocol checking was exercised, not vacuously green. Signing off on passing assertions alone is date-gated-style false closure for the assertion layer.
• Cover properties also measure protocol-scenario coverage. Beyond antecedents, cover property on interesting sequences (back-to-back, error-during-burst) measures the protocol scenarios exercised — feeding the functional coverage picture from the signal/protocol angle.

The motivation, in one line: a passing assertion is the assertion-layer "passing test" — necessary but not sufficient, because a vacuous pass checks nothing; so the protocol layer needs both correctness (assertions hold) and completeness (assertion coverage — the rules exercised), with assertion coverage turning the vacuous-pass worry into a measurable gap and feeding the closure picture — uniting assertions and coverage on the same two orthogonal questions as the scoreboard and functional coverage.

Mental Model

Hold assertion/coverage synergy as the sentry and the log of who approached the post — no alarms is only reassuring if the log shows the post was actually tested:

An assertion is a sentry that sounds an alarm when a rule is broken — that's correctness, the checking. But a sentry that reports no alarms could mean two very different things: either people approached the post and were correctly cleared (the rule was exercised and held), or no one ever approached the post at all (the rule was never tested). You cannot tell these apart from the absence of alarms. So you keep a second record: a log of whether anyone ever approached the post — that's the cover property, the completeness measurement. Now no alarms plus a log showing the post was approached and tested means real assurance: the rule was exercised and it held. But no alarms plus a log showing no one ever approached means the sentry verified nothing — a vacuous pass, false assurance. Closing out the post requires both: no alarms, and a log proving the post was actually tested. A guard force signed off on no-alarms alone has posts that may never have been challenged, and the one unchallenged post is exactly where the intruder walks through. Picture each assertion as a sentry that sounds an alarm when its rule is broken — that's correctness, the checking. But a sentry reporting no alarms could mean two very different things: either people approached the post and were correctly cleared (the rule was exercised and held), or no one ever approached the post at all (the rule was never tested). You cannot tell these apart from the absence of alarms. So you keep a second record: a log of whether anyone ever approached the post — that's the cover property, the completeness measurement. Now no alarms plus a log showing the post was approached and tested means real assurance (the rule was exercised and it held). But no alarms plus a log showing no one ever approached means the sentry verified nothing — a vacuous pass, false assurance. Closing out the post requires both: no alarms, and a log proving the post was actually tested. A guard force signed off on no-alarms alone has posts that may never have been challenged — and the one unchallenged post is exactly where the intruder walks through (the un-exercised assertion guarding the shipped bug). This is the same two-record discipline as the transaction layer (Module 19.1): the scoreboard (alarm) plus functional coverage (the log) — here it's the assertion (alarm) plus assertion coverage (the log), for the signal/protocol posts.

So assertion/coverage synergy is the sentry and its approach-log: the assertion (sentry) checks correctness (rule held — no alarm), and the cover property (log) measures completeness (rule exercised — the post was approached). No alarms alone is ambiguous — real assurance (exercised-and-held) or vacuous (never-tested) — and only the log (cover property) distinguishes them. Closing a post requires both: passing (no alarm) AND covered (the post was tested). Measure both — did the rule hold, and was the rule exercised — because no-alarms on an untested post is false assurance.

Visual Explanation — the two questions for the protocol layer

The defining picture is the parallel: the protocol layer asks the same two orthogonal questions as the transaction layer (19.1) — correctness (assertions) and completeness (assertion coverage).

The figure shows the two orthogonal questions for the protocol layer. Correctness: do the protocol rules hold? — answered by assertions (fire on violation). Completeness: were the protocol rules actually exercised? — answered by assertion coverage (cover property). The crucial reading is the exact parallel to Module 19.1's transaction layer: there, the scoreboard answered correctness and functional coverage answered completeness; here, assertions answer correctness and assertion coverage answers completeness — the same two orthogonal questions, now for the signal/protocol layer. They're orthogonal: an assertion answers only correctness (does the rule hold on what was exercised?), a cover property answers only completeness (was the rule exercised?). Neither alone gives confidence in the protocol checking: assertions without coverage leave you unable to tell a real pass from a vacuous one (passing but checked nothing); coverage without assertions measures exercise but checks no correctness. Confidence (the warning-colored outcome) requires both — the rules hold (assertions) AND the rules were exercised (assertion coverage). The brand-colored questions map to the success-colored answers (assertions, assertion coverage), both feeding confidence. This is the unifying insight of the chapter: the protocol layer is not special — it has the same correctness/completeness structure as the transaction layer, and the same requirement for both halves. A passing assertion with no coverage is exactly the protocol-layer form of "passing tests with low coverage" (19.1) — green but unverified. The diagram is the two-question parallel: correctness (assertions) ⊥ completeness (assertion coverage), both required — the transaction-layer structure (scoreboard + functional coverage) repeated for the protocol layer. Assertions check the rules hold; assertion coverage checks the rules were exercised — both, for confidence in the protocol checking.

RTL / Simulation Perspective — cover properties measuring the checks

In code, assertion coverage is cover property — on the antecedent (did the assertion run?) and on the scenario (did the interesting sequence occur?). The example shows assertions paired with their coverage.

// === THE ASSERTION: correctness — does the handshake rule hold? ===
a_handshake: assert property (@(posedge clk) disable iff (!rst_n) req |-> ##[1:3] ack);
 
// === ANTECEDENT COVERAGE: did the assertion actually RUN (not vacuously pass)? ===
c_req_seen:  cover property (@(posedge clk) req);
//   0 hits → the antecedent NEVER fired → a_handshake passed VACUOUSLY → a coverage GAP (21.4)
 
// === SCENARIO COVERAGE: did the full INTERESTING protocol sequence occur? ===
c_handshake_exercised: cover property (@(posedge clk) req ##[1:3] ack);  // the req-then-ack scenario
c_ack_at_max:          cover property (@(posedge clk) req ##3 ack);      // ack at the MAX latency (corner)
c_back_to_back:        cover property (@(posedge clk) ack ##1 req);      // back-to-back (stress corner)
 
// === ASSERTION COVERAGE FEEDS CLOSURE alongside functional + code coverage (Module 19.6/19.7) ===
//   closure requires:  a_handshake PASSING (correctness)  AND  c_req_seen + scenarios HIT (completeness)
 
// ✗ MISTAKE: sign off on "a_handshake PASSING" with c_req_seen at 0 hits → the assertion checked NOTHING
//            → the protocol scenario was never exercised → the bug it guards SHIPS (DebugLab)

The code shows assertions paired with their coverage. The assertion (a_handshake) is correctness — does the handshake rule hold? Antecedent coverage (c_req_seen: cover property (req)) is completeness of the check itself — did the assertion actually run? A 0-hit c_req_seen means the antecedent never fired, so a_handshake passed vacuously — a coverage gap (21.4). Scenario coverage (c_handshake_exercised: cover property (req ##[1:3] ack), c_ack_at_max: ... req ##3 ack, c_back_to_back: ... ack ##1 req) measures whether the full interesting protocol sequences occurred — the req-then-ack scenario, the ack at max latency corner, the back-to-back stress. Assertion coverage feeds closure alongside functional and code coverage (Module 19.6/19.7) — closure requires a_handshake passing (correctness) AND c_req_seen plus the scenarios hit (completeness). The mistake (commented) is signing off on "a_handshake passing" with c_req_seen at 0 hits — the assertion checked nothing, the protocol scenario was never exercised, and the bug it guards ships (the DebugLab). The shape to carry: each meaningful assertion is paired with cover properties — at least the antecedent (to catch vacuous passes) and often the interesting scenarios (to measure protocol-scenario coverage). The antecedent cover is the vacuous-pass detector: it turns the "did this assertion check?" worry into a measured number (c_req_seen hits). The scenario covers are protocol-scenario coverage — the signal/protocol angle on functional coverage (the corners like max-latency ack and back-to-back). And closure of the assertion layer gates on both: assertions passing (no violations) AND covers hit (the rules and scenarios exercised). Pair every assertion with antecedent and scenario coverage — passing tells you it held, the cover tells you it ran.

Verification Perspective — passing-and-covered versus passing-but-vacuous

The decisive distinction is among passing assertions: passing-and-covered (real assurance) versus passing-but-uncovered (vacuous, false assurance). Seeing the quadrants clarifies what closure requires.

The figure shows the assertion states — and why closure requires both passing and covered. Passing and covered (the brand-colored top): the antecedent fired (the rule was exercised) and there was no violation (the rule held) → real assurance, the closed state. Passing but uncovered (the warning-colored middle): the antecedent never fired, so the rule was never exercised and the assertion verified nothing → a vacuous pass, false assurance, an assertion-coverage gap — not closed. Firing (the brand-colored bottom): the antecedent fired and a violation was found → a real catch to debug (Module 21.4). The verification insight is that "passing" splits into two very different states — and only coverage distinguishes them. Passing-and-covered is what you want (exercised and held); passing-but-uncovered is the trap (looks green, checked nothing). Without assertion coverage, both report "passing" and are indistinguishable — so a verifier cannot tell a verified rule from an un-exercised one. This is exactly the transaction-layer lesson (19.1's quadrants: checked-and-covered vs checked-but-not-covered) for the assertion layer: the checked-but-not-covered quadrant (passing, vacuous) is false confidence. So closure of an assertion requires both: passing (correctness — no violation) AND covered (completeness — the antecedent/scenario exercised). A passing-but-uncovered assertion is not closed — it's a coverage gap, just like an unhit functional bin. The brand-colored passing-and-covered (and firing) are the resolved states (closed, or a catch to debug); the warning-colored passing-but-uncovered is the unresolved gap. The figure is the closure criterion for an assertion: passing AND covered → closed; passing but uncovered → a vacuous gap; firing → a catch to debug — and only passing-and-covered is real assurance. A passing assertion is closed only if it's also covered; passing-but-uncovered is a vacuous gap that checked nothing.

Runtime / Execution Flow — a vacuous pass is a coverage gap, closed by the loop

At run time, the vacuous-pass-as-coverage-gap insight connects to the coverage-feedback loop (Module 20.4): a 0-hit antecedent is a gap that stimulus steering closes. The flow shows the connection.

The flow shows that a vacuous pass is a coverage gap closed by the feedback loop. Zero hits (step 1): the cover property on the assertion's antecedent was never hit — the assertion passed vacuously. Gap (step 2): it's a coverage gap = a stimulus gap — the antecedent's scenario was never generated, so the assertion checked nothing, exactly like an unhit functional bin. Steer (step 3): bias constraints or add a directed test to exercise the antecedent — the coverage-feedback loop (Module 20.4). Confirm (step 4): re-run — the antecedent now fires, the cover is hit, and the assertion actually evaluates its rule on the scenario. The runtime insight is that the vacuous pass is not a separate problem with its own fix — it's the same kind of gap as any coverage gap, routed through the same loop. This is the deep synergy: assertion coverage (the antecedent/scenario covers) is just more coverage, analyzed and steered exactly like functional coverage (Module 19.6, 20.4). A 0-hit antecedent is ranked, classified, and steered toward alongside unhit functional bins — bias the randomization (or add a directed test) to exercise the antecedent, re-run, and confirm the cover is hit (the assertion now checks). The crucial point is that the fix is stimulus, not the assertion — the assertion is fine; it just needs its triggering scenario exercised (Module 21.4). So the assertion layer folds into the coverage-driven methodology: assertions provide correctness checks, their cover properties provide completeness measurement, and the gaps (vacuous passes) drive the same feedback loop that closes functional coverage. The flow is the fold-in: 0-hit antecedent → coverage gap = stimulus gap → steer → re-run → covered — the vacuous pass closed by the coverage-feedback loop, no special handling. A vacuous pass is just a coverage gap — steer stimulus to exercise the antecedent, and the assertion starts checking.

Waveform Perspective — cover properties recording the checks

Assertion coverage is visible as cover properties recording when the antecedent and scenario occur — and where they don't (a gap). The waveform shows the covers firing and an uncovered region.

The waveform shows assertion coverage recording the checks. The handshake assertion runs whenever req fires. The antecedent cover (cov_req) records each time req occurs — proving the assertion actually ran there. The scenario cover (cov_scenario) records when the full req-then-ack sequence completes — the interesting protocol scenario exercised. In the early region, req fires and the sequence completes, so both covers are hit and the assertion really checked. In the later region, req never fires (no_req), so the assertion passes vacuously and the covers stay unhit — a visible assertion-coverage gap. The crucial reading is that the cover properties make the assertion's activity visible: cov_req hitting means the assertion ran (the antecedent occurred), and cov_scenario hitting means the full protocol scenario was exercised — so a verifier can see, region by region, where the assertion actually checked (covers hit) versus where it passed vacuously (covers unhit). The unhit covers in the later region are the visible signature of a vacuous pass — the assertion was green there, but it checked nothing (no antecedent), so the covers expose the gap the passing status hides. This is the completeness measurement of the protocol checking: not "did the assertion pass?" (it did, everywhere) but "where did the assertion actually check?" (only where cov_req is hit). The picture to carry is that cover properties are the assertion's coverage — they record when the antecedent and scenario occur, exposing the vacuous regions where the passing assertion verified nothing. Reading the waveform this way — where did the covers fire (real checks) and where are they unhit (vacuous gaps)? — is reading the protocol-checking completeness. The covers hitting in the exercised region and unhit in the no-antecedent region is the signature of assertion coverage doing its job: making visible where the assertion checked and where it didn't. Cover properties record where the assertion actually checked — the unhit regions are the vacuous gaps the passing status hides.

DebugLab — the all-green assertion suite that guarded nothing

✗ SIGN OFF on "all assertions PASSING" (correctness only, no assertion coverage):
  a_retry_handshake: assert property (...);   // PASSES — millions of cycles, green
  // BUT: cover property (retry_antecedent) = 0 hits → the retry scenario was NEVER generated
  //      → a_retry_handshake passed VACUOUSLY → it checked NOTHING, every cycle
  // "all passing" is INDISTINGUISHABLE from "all vacuous" without coverage
  // the retry-handshake bug ships, uncaught by the assertion written to catch it
 
✓ GATE closure on BOTH passing AND covered (correctness AND completeness):
  c_retry_seen: cover property (retry_antecedent);   // pair every critical assertion with its cover
  // closure requires: a_retry_handshake PASSING  AND  c_retry_seen HIT
  // c_retry_seen at 0 → NOT closed → a coverage gap → steer stimulus to the retry scenario (20.4)
  // re-run: retry scenario exercised → assertion ACTUALLY checks → catches the bug before tapeout

Common Mistakes

• Signing off on 'all assertions passing' without coverage. Passing alone can't distinguish real checks from vacuous passes; require assertion coverage too.
• Not covering antecedents. Without an antecedent cover, a vacuously-passing assertion looks identical to a real one; cover every meaningful assertion's antecedent.
• Treating assertion coverage as separate from closure. Assertion coverage is part of the closure picture alongside functional and code coverage; gate sign-off on it.
• Changing the assertion to fix a vacuous pass. The assertion is fine; the antecedent was never exercised — steer stimulus, don't alter the assertion.
• Ignoring protocol-scenario coverage. Cover properties on corners measure protocol completeness from the signal angle; skipping them leaves protocol gaps.
• Forgetting the parallel to functional coverage. The protocol layer has the same correctness/completeness pair as the transaction layer; treat assertion coverage like functional coverage.

Senior Design Review Notes

Interview Insights

Exercises

1. Pair the coverage. For a handshake assertion, write the antecedent cover and two scenario covers (a corner and a stress case).
2. Diagnose the vacuous pass. An assertion passes but its antecedent cover is 0. State what it means, why it's a coverage gap, and the fix.
3. State the closure criterion. Explain why an assertion is closed only when both passing and covered, and what each half rules out.
4. Map the parallel. Match the assertion layer's correctness and completeness mechanisms to their transaction-layer counterparts.

Summary

• Assertion/coverage synergy unites the two orthogonal questions for the protocol layer: assertions check correctness (do the rules hold?), and assertion coverage (cover property) checks completeness (were the rules exercised?) — the same pair as the scoreboard + functional coverage (Module 19.1), now for the signal/protocol layer.
• A cover property measures whether a sequence occurred: antecedent coverage (cover property (req) — did the assertion run, not vacuously?) and scenario coverage (cover property (req ##[1:3] ack) — were the interesting protocol scenarios exercised?).
• A vacuous pass is exactly an assertion-coverage gap — a 0-hit antecedent cover — and also a stimulus gap, so it routes through the coverage-feedback loop (Module 20.4): steer stimulus to exercise the antecedent; the fix is stimulus, not the assertion.
• Closing the assertion layer requires both: all assertions passing (correctness) AND all assertion coverage hit (completeness) — a passing-but-uncovered assertion checked nothing, and "all green" is indistinguishable from "all vacuous" without coverage.
• The durable rule of thumb: assertions and coverage close the loop on the protocol layer the same way the scoreboard and functional coverage do on the transaction layer — assertions check the rules hold, cover properties check the rules were exercised, and you need both; pair every meaningful assertion with antecedent and scenario coverage, gate closure on passing AND covered, and treat a vacuously-passing assertion as an open coverage gap to close with stimulus, because a passing assertion that was never exercised is a guard reporting 'all clear' from a post no one ever approached.

Next — Why Callbacks Exist: the next module turns to a different challenge — extending reusable components. A vendor VIP or shared agent is sealed, yet each test and team needs a small tweak at a specific point — error injection before driving, logging after receiving. The module opens with why callbacks exist: why modifying the source breaks reuse and whole-type factory override is the wrong tool for a point-tweak, and how callback hooks let users inject behavior at predefined points — additively, with multiple customizations coexisting — without ever forking the component.