Assertion Debug

Assertions in UVM · Module 21 · Page 21.4

The Engineering Problem

An assertion's great strength is precision: when it fires, it points at the exact cycle and names the property — so, unlike a scoreboard mismatch (which surfaces late and must be traced back), the location is given for free. But that strength hides a subtlety: the hard question is not "where" — it's "why" and "whose fault." A fired assertion is not automatically a DUT bug. It might be a real DUT bug (the design violated a correct rule), or a wrong assertion (too strict, wrong condition, wrong operator — Module 21.2), or an unguarded assertion firing on reset-state or X/unknown signals, or a sampling artifact. Assuming the fire means a DUT bug and debugging the RTL for days — when the assertion was wrong or unguarded — wastes the effort on an innocent DUT, exactly as trusting a scoreboard's accusation does (Module 18.7). And the opposite failure mode — an assertion that passes vacuously (its antecedent never fired) — checks nothing while looking green. The problem this chapter solves is assertion debug: the systematic process from a fired assertion to its true cause — auditing the assertion and the DUT — and diagnosing the vacuous-pass gap.

Assertion debug is finding the true cause of a fired assertion (or a vacuous pass). Because the fire is precise (the report gives the property, the failure cycle, the start cycle where the antecedent matched, and the signal values along the failing attempt), the task is not "where" but "why" and "whose fault" — a two-way audit. Audit the assertion against the spec: is it a faithful statement of the rule — the right window, condition, operator, and properly guarded (disable iff reset, X-handling)? If not, it's a wrong/too-strict/unguarded assertion (fix the assertion). Audit the DUT against the waveform: at the failing attempt, did the DUT really violate the rule — or is the fire a reset-state, X, or sampling artifact? Only if the assertion is correct and the DUT truly violated it (not an artifact) is it a real DUT bug (debug the RTL). The other debug scenario is the vacuous pass: an assertion passing without checking (antecedent never fired) — diagnosed via assertion coverage (a 0-hit antecedent), fixed by stimulus (steer to exercise it — Module 20.4), not by changing the assertion. This chapter is assertion debug: reading the report, reconstructing the attempt, the two-way audit, distinguishing real-bug from wrong-assertion, vacuity, and the systematic process.

How do you debug a fired assertion — read the failure report and reconstruct the failing attempt, audit the assertion against the spec and the DUT against the waveform, distinguish a real DUT bug from a wrong, too-strict, or unguarded assertion (reset, X, sampling), and handle the vacuous-pass case where an assertion checks nothing?

Motivation — why a precise fire still needs a careful audit

The precision of an assertion fire is seductive — it tempts you to jump to the DUT. The reasons a careful audit is essential:

• A fire is an accusation, not a verdict. The assertion says the rule was broken — but the rule (the assertion) might be wrong, or the evidence (the signals) might be an artifact. Trusting the fire blindly and debugging the DUT risks days on an innocent design (Module 18.7's lesson, for assertions).
• Assertions have their own failure modes. Too strict (wrong window — 21.2), wrong condition, wrong operator (|-> vs |=>), missing disable iff (fires during reset), X/unknown propagation, sampling/clocking races — any of these makes a correct DUT fire a wrong assertion. The fire doesn't distinguish them from a real bug.
• The fire gives the location, so the audit can be focused. The report's precision (property, cycle, start, signals) is a gift — it lets the audit be targeted: you reconstruct the exact failing attempt and check it against the spec and the waveform, quickly.
• Reset, X, and sampling are common and assertion-specific. A huge fraction of spurious fires are reset-state (missing disable iff), X values (uninitialized signals), or sampling (the assertion samples preponed values). Recognizing these is a core assertion-debug skill.
• The vacuous pass is the silent failure. The opposite problem — an assertion that never fires its check (antecedent never exercised) — looks like success but verifies nothing. Diagnosing it (via assertion coverage) is part of assertion debug.

The motivation, in one line: an assertion fire is precise but not a verdict — it could be a real DUT bug or a wrong/too-strict/unguarded assertion (reset, X, sampling), so jumping to the DUT risks days on an innocent design; the precision lets the audit be focused (reconstruct the attempt, check assertion-vs-spec and DUT-vs-waveform), and the vacuous pass (an assertion that checks nothing) is the silent counterpart — so assertion debug is a careful, systematic audit, not a jump to the RTL.

Mental Model

Hold assertion debug as a sentry's alarm at a precise post and time — go to the scene, but audit whether the standing order was right and whether something real tripped it:

When a sentry's alarm goes off, you know exactly which post and what time — that's the assertion's precision, and it saves you the search. But the alarm itself is not proof of an intruder. Before you mobilize a manhunt (debug the DUT), you audit two things. First, the standing order: was the sentry's rule a faithful statement of the actual policy? A sentry told to sound the alarm if anyone passes within two seconds, when the policy allows three, will alarm on perfectly authorized people — a wrong order, not an intruder. Second, the evidence: did something real actually trip the alarm, or was it a false trigger — the alarm wired to go off during the nightly reset, or triggered by a sensor reading static (an X) before the system powered up, or by a mis-timed sample? Only if the standing order was correct and something real genuinely tripped it do you have an intruder (a real DUT bug). And there's a quieter failure: an alarm that never sounds because no one ever approached its post — the sentry verified nothing, not because all is well, but because nothing was ever tested there (a vacuous pass). Picture an assertion fire as a sentry's alarm at a precise post and time. The precision (the cycle and the property) saves you the search — you go straight to the scene. But the alarm is not proof of an intruder. Before you mobilize a manhunt (debug the DUT), you audit two things. First, the standing order: was the sentry's rule (the assertion) a faithful statement of the actual policy (the spec)? A sentry told to alarm if anyone passes within two seconds, when the policy allows three, alarms on authorized people — a wrong order (too-strict assertion), not an intruder. Second, the evidence: did something real actually trip the alarm, or was it a false trigger — the alarm wired to go off during the nightly reset (missing disable iff), triggered by a sensor reading static (an X) before power-up, or by a mis-timed sample? Only if the standing order was correct and something real genuinely tripped it do you have an intruder (a real DUT bug). And there's a quieter failure: an alarm that never sounds because no one ever approached its post — the sentry verified nothing, not because all is well, but because nothing was ever tested there (a vacuous pass).

So assertion debug is auditing a precise alarm: the fire gives the scene (cycle + property — no search), but you audit the standing order (is the assertion faithful to the spec — right window/condition/operator/guards?) and the evidence (did the DUT really violate, or is it a reset/X/sampling false trigger?). Only a correct order truly tripped is an intruder (real DUT bug). And the quiet failure is the alarm that never sounds (vacuous pass — antecedent never approached). Go to the scene the fire gives you, but audit the order and the evidence before convicting the DUT — and watch for the alarm that never checked anything.

Visual Explanation — what a fired assertion could mean

The defining picture is the fork: a fire is one of a real DUT bug, a wrong assertion, or an artifact — and the audit determines which.

The figure shows the fork a fired assertion presents. The fire (the warning-colored center — precise cycle + property) could be a real DUT bug (the design violated a correct, well-guarded assertion), or a wrong assertion (too strict, wrong condition, or wrong operator — firing on legal behavior), or an artifact (reset — missing disable iff; X/unknown values; sampling/clocking). The crucial reading is that the fire itself doesn't distinguish these — all present as "assertion X fired at cycle T." So the debugging task is determining which, by auditing: the wrong-assertion branch is found by checking the assertion against the spec (is the window/condition/operator correct?); the artifact branch is found by checking the failing cycle's context (was it reset? are signals X? a sampling race?); and only when both audits clear (the assertion is correct and guarded, the violation is real) is it a real DUT bug. The brand-colored real-DUT-bug is the conclusion only after the success-colored wrong-assertion and artifact branches are ruled out. This mirrors scoreboard debug (Module 18.7): don't convict the DUT until you've audited the accuser (the assertion) and the evidence (the waveform). The insidious trap is following only the real-DUT-bug branch — assuming the fire is a design bug and debugging the RTL — when the wrong-assertion or artifact branches are more often the cause (especially early in a project, when assertions are new and un-vetted). The diagram is the cause map: one fire → three possible causes (real bug / wrong assertion / artifact) → audit to determine — and the audit, not the fire, gives the verdict. A fire is one of real-bug, wrong-assertion, or artifact — audit to determine which, don't assume a DUT bug.

RTL / Simulation Perspective — reading the report and auditing

In code (and in the report), the debug is reconstruct the failing attempt, then audit the assertion and the DUT. The example shows a report, the reconstruction, and the audit checks.

// === THE FAILURE REPORT (from the simulator) ===
//   "a_handshake" FAILED at time 1850ns (cycle 185)
//      property: req |-> ##[1:3] ack
//      antecedent matched (started) at cycle 182; consequent NOT satisfied by cycle 185
//      signals: req=1@182, ack=0 @183,184,185, rst_n=1, all defined
 
// === RECONSTRUCT THE FAILING ATTEMPT on the waveform ===
//   cycle 182: req rose (antecedent) → attempt starts
//   cycles 183,184,185: ack never asserted → window [1:3] elapsed → FIRE at 185
 
// === AUDIT 1: is the ASSERTION faithful to the spec? ===
//   spec says "ack within 1 to 3 cycles" → ##[1:3] is CORRECT (not too strict/loose)
//   operator |-> correct? spec means ack AFTER req → arguably |=> ... but [1:3] covers it → OK
//   guarded? disable iff (!rst_n) present, rst_n=1 at failure → NOT a reset artifact
//   signals defined (no X) → NOT an X artifact
 
// === AUDIT 2: did the DUT REALLY violate it? ===
//   waveform: ack genuinely never asserted in 183..185 → REAL violation (not a sampling artifact)
//   → ASSERTION correct + guarded, DUT truly violated → REAL DUT BUG → debug the RTL
 
// ✗ CONTRAST — an UNGUARDED assertion firing at reset (the DebugLab):
//   a_x: assert property (req |-> ##[1:3] ack);   // ← NO disable iff (!rst_n)
//   fires at cycle 2 during reset, req/ack are reset-state/X → ARTIFACT, not a DUT bug

The code shows the debug flow. The failure report gives the assertion name (a_handshake), the time/cycle of failure (1850ns, cycle 185), the property (req |-> ##[1:3] ack), the antecedent start (cycle 182), and the signals along the attempt (req=1@182, ack=0@183,184,185, rst_n=1, all defined). Reconstruct the failing attempt: cycle 182 req rose (attempt starts), cycles 183–185 ack never asserted, window [1:3] elapsed → fire at 185. Audit 1 (assertion vs spec): the spec says "ack within 1 to 3 cycles" → ##[1:3] is correct (not too strict/loose); the operator is reasonable; it's guarded (disable iff (!rst_n) present, rst_n=1 at failure → not a reset artifact); signals defined (no X). Audit 2 (DUT vs waveform): ack genuinely never asserted in 183–185 → a real violation (not a sampling artifact). Conclusion: assertion correct and guarded + DUT truly violated → real DUT bug → debug the RTL. The contrast (commented) is an unguarded assertion (a_x with no disable iff) firing at cycle 2 during reset on reset-state/X signals → an artifact, not a DUT bug (the DebugLab). The shape to carry: assertion debug is (1) reconstruct the failing attempt from the report (antecedent cycle, window, what happened), (2) audit the assertion against the spec (window, condition, operator, guards), and (3) audit the DUT against the waveform (real violation vs reset/X/sampling artifact) — concluding a real DUT bug only when both audits clear. The report's precision makes step (1) fast (the cycles and signals are given); the audits (steps 2–3) are where the true cause is found. The guards check (disable iff, X) is assertion-specific — a huge fraction of spurious fires are reset or X, and checking rst_n and signal-definedness at the failure cycle immediately rules them in or out. Reconstruct the attempt, audit the assertion's correctness and guards, audit the DUT's real behavior — conclude a DUT bug only when both clear.

Verification Perspective — the two-way audit

The core of assertion debug is the two-way audit — the assertion (vs the spec) and the DUT (vs the waveform). Seeing both axes, with what each rules in or out, is the diagnostic.

The figure shows the two-way audit. Audit the assertion against the spec (the brand-colored top): is the window, condition, and operator faithful, and is it guarded against reset and X? If not, it's a wrong or unguarded assertion → fix the assertion. Audit the DUT against the waveform at the failing attempt (the brand-colored bottom): did the consequent genuinely not hold, with defined signals out of reset — or is it a sampling artifact? If the violation isn't real, it's an artifact → guard / fix sampling. Only when the assertion is correct and guarded AND the DUT genuinely violated it is the fire a real DUT bug (the success-colored conclusion — both audits clear, the bus edges). The verification insight is that the two audits are independent and both necessary: the assertion could be wrong (a correct DUT fires a bad assertion), or the evidence could be an artifact (a correct DUT fires a good assertion spuriously, e.g. during reset), or both could clear (a real bug). Skipping the assertion audit risks debugging the DUT for a wrong-assertion fire; skipping the DUT audit risks "fixing" a real bug as an artifact (or vice versa). The assertion audit checks fidelity (Module 21.2 — the right window/condition/operator) and guards (disable iff reset, X-handling — assertion-specific). The DUT audit checks the waveform — did the consequent really not hold, with defined signals out of reset, not a sampling race? The brand-colored audits gate the success-colored real-DUT-bug conclusion. This is the operational form of "audit the accuser and the evidence before convicting the accused" (Module 18.7, for assertions): both the assertion (accuser) and the waveform evidence must clear before the DUT (accused) is convicted. The figure is the audit: fire → (audit assertion: correct+guarded?) + (audit DUT: real violation?) → both clear → real DUT bug — two independent audits, both required. Audit the assertion's correctness and guards and the DUT's real behavior; only when both clear is it a DUT bug.

Runtime / Execution Flow — the systematic process

At debug time, assertion debug is a fixed process: read the report, reconstruct the attempt, audit the assertion, audit the DUT, conclude. The flow shows it.

The flow shows the systematic process. Read (step 1): the failure report — the property, the failure cycle, the antecedent start cycle, and the signals along the failing attempt. Reconstruct (step 2): the failing attempt on the waveform — where the antecedent matched, the window, and what the consequent actually did. Audit (step 3): the assertion vs the spec (window, condition, operator, guards) and the DUT vs the waveform (genuine violation vs reset/X/sampling). Conclude (step 4): wrong/unguarded assertion (fix it), artifact (guard it), or — both audits clear — a real DUT bug (debug the RTL). The runtime insight is that this process exploits the fire's precision: steps 1–2 are fast (the report gives the cycles and signals, so reconstructing the attempt is direct — no tracing back, unlike a scoreboard mismatch), and the effort goes into steps 3–4 (the audits and the conclusion). The process guarantees you never debug the DUT until the assertion and the evidence are cleared — the cardinal discipline. The assertion audit (step 3) often short-circuits the debug: if the assertion is too strict (wrong window) or unguarded (fires during reset), the fire is explained without the DUT — saving the days a jump-to-RTL would waste. The DUT audit (step 3) catches the artifacts — reset, X, sampling — that look like violations but aren't. Only when both audits clear does step 4 reach "real DUT bug." The process is the debugging loop for an assertion: read (precise report) → reconstruct (the attempt) → audit (assertion + DUT) → conclude (wrong-assertion / artifact / real-bug) — a deterministic path from a fired assertion to its true cause, exploiting the precision while auditing the accusation. Read the report, reconstruct the attempt, audit both the assertion and the DUT, and conclude — never jump to the RTL before the audits clear.

Waveform Perspective — reading the failing attempt

The debug happens on the waveform: you reconstruct the failing attempt — antecedent, window, consequent — and read whether the violation is real. The waveform shows a real violation and a vacuous (no-check) attempt.

The waveform shows reading the failing attempt. The assertion is req |-> ##[1:3] ack, with rst_n high (out of reset) and signals defined (no X). In the first attempt, req rises (antecedent) and the window opens; ack genuinely never asserts within the window, so the assertion fires (cycle 4) — and the waveform confirms it's a real violation, not a reset or X artifact (rst_n=1, signals defined). Later, req never rises, so no attempt starts and the assertion passes vacuously, checking nothing in that region. The crucial reading is the two diagnoses the waveform supports. First, was the fire real? — at the failing attempt, you check: did the antecedent match (req rose)? was it out of reset (rst_n=1)? were the signals defined (no X)? did the consequent genuinely not hold (ack truly absent in the window)? All yes → a real violation (the assertion correctly caught a DUT bug). If any no (reset, X, antecedent-didn't-really-match) → an artifact. Second, did a pass actually check? — in the vacuous region, req never rose, so the assertion passed without checking — a pass that verifies nothing (the vacuous-pass diagnosis). The picture to carry is that the waveform is the audit surface: you reconstruct the failing attempt and read the signals at the failure cycle to distinguish a real violation (antecedent matched, out of reset, defined, consequent truly absent) from an artifact (reset/X/sampling), and you read whether a passing region actually checked (antecedent fired) or passed vacuously. Reading the waveform this way — at the failing attempt, is the violation genuine and the assertion properly conditioned? and elsewhere, did the assertion actually check? — is the heart of assertion debug. The genuine fire (out of reset, defined, consequent absent) versus the vacuous region (no antecedent) is the signature of reading an assertion's behavior: real violation here, no check there. The waveform is where you audit the fire — confirm the antecedent matched, the signals were valid, and the consequent truly failed, before calling it a DUT bug.

DebugLab — three days debugging a DUT that never had the bug

✗ ASSUME the fire is a DUT bug → debug the RTL (no assertion audit):
  a_resp_valid: assert property (@(posedge clk) start |-> ##[1:2] resp_valid);  // ← NO disable iff!
  // fires at cycle 2 DURING RESET → signals are reset-state/X → spurious fire
  // team sees "assertion fired" → assumes DUT bug → traces RTL for 3 DAYS → finds nothing (DUT is fine)
 
✓ AUDIT the assertion FIRST — check the failing cycle's context:
  // look at the failure cycle: rst_n=0 (in reset!) → the fire is a RESET ARTIFACT, not a DUT bug
  // FIX: guard the assertion against reset
  a_resp_valid: assert property (@(posedge clk) disable iff (!rst_n) start |-> ##[1:2] resp_valid);
  // now the assertion doesn't evaluate during reset → no spurious fire → real violations still caught
  // a 30-SECOND audit (check rst_n at the failure cycle) would have saved 3 DAYS

Common Mistakes

• Assuming a fire is a DUT bug. A firing assertion is as likely a wrong or unguarded assertion; audit the assertion before opening the RTL.
• Not checking reset and X at the failure cycle. A fire during reset (missing disable iff) or on X values is an artifact, not a violation; check rst_n and definedness first.
• Skipping the property audit. A too-strict, wrong-condition, or wrong-operator assertion fires on legal behavior; confirm fidelity to the spec.
• Ignoring vacuous passes. An assertion whose antecedent never fires passes without checking; diagnose via assertion coverage and steer stimulus, not by changing the assertion.
• Not reconstructing the failing attempt. Debugging without the antecedent cycle, window, and signals guesses; the report gives them — reconstruct the attempt precisely.
• Fixing a real bug as an artifact (or vice versa). Both audits must clear; don't guard away a real violation or chase an artifact into the RTL.

Senior Design Review Notes

Interview Insights

Exercises

1. Reconstruct the attempt. Given a report (property, failure cycle 185, antecedent at 182, signals), describe the failing attempt and the first audit you'd run.
2. Classify the fire. For a fire at cycle 2 with rst_n low, a fire on a legal max-latency response, and a fire with a genuinely-absent consequent out of reset, name the cause of each.
3. Add the guard. Write the reset guard for an assertion firing at start-of-test, and explain why it fixes the spurious fire.
4. Diagnose the vacuous pass. An assertion passes but its antecedent cover is 0. Explain what that means and the fix.

Summary

• Assertion debug is finding the true cause of a fired assertion — and because the fire is precise (the report gives the property, failure cycle, antecedent start, and signals), the task is not "where" but "why" and "whose fault."
• It is a two-way audit: audit the assertion against the spec (faithful window, condition, operator, and guarded against reset and X) and audit the DUT against the waveform (a genuine violation vs a reset, X, or sampling artifact) — only when both clear is it a real DUT bug.
• The cardinal rule mirrors scoreboard debug (Module 18.7): a firing assertion is as likely a wrong or unguarded assertion as a real DUT bug, so audit the accuser (the assertion) before convicting the accused (the DUT) — jumping to the RTL wastes days on an innocent design.
• The vacuous pass is the silent case: an assertion passing without checking (antecedent never fired) — diagnosed via a 0-hit antecedent cover, fixed by stimulus (steer to exercise it), not by changing the assertion.
• The durable rule of thumb: an assertion fire is a precise accusation, not a verdict — reconstruct the failing attempt from the report, then audit the assertion (is the window/condition/operator faithful, and is it guarded against reset and X?) and the DUT (a genuine violation, or a reset/X/sampling artifact?), and conclude a real DUT bug only when both clear; check rst_n and definedness at the failure cycle first, because a 30-second assertion audit saves the days otherwise lost debugging an innocent design — and watch for vacuous passes that check nothing.

Next — Assertion Coverage Synergy: the module closes by uniting assertions and coverage — the synergy between assertion-based checking and functional coverage. How cover properties measure that assertions actually fired their checks, how assertion coverage feeds the closure picture, how vacuous passes connect to coverage gaps, and how assertions and coverage together close the loop on both correctness and completeness of the protocol checking.