SVA Integration

Assertions in UVM · Module 21 · Page 21.1

The Engineering Problem

The verification machine built across the prior modules has two checking and measuring layers: the scoreboard (Module 18) verifies transaction-level correctness — observed output versus independently-computed expected, end-to-end — and functional coverage (Module 19) measures completeness. But both work at the transaction abstraction — and that abstraction hides a whole class of bugs: the cycle-by-cycle protocol and timing rules on the interface signals. Did VALID stay asserted until READY? Did REQ get an ACK within the required window? Did the bus ever drive two grants in the same cycle? The scoreboard, comparing assembled transactions, can't see these mid-transaction, signal-level, temporal rules — and a violation of one is a real bug that the transaction-level check misses. SystemVerilog Assertions (SVA) are the complementary layer that closes this gap: continuously-evaluated, concurrent rules about signal behavior over time, firing precisely at the exact cycle and signal of a violation. The problem this chapter solves is SVA integration: what assertions are as a checking layer, where they live and how bind attaches them non-intrusively, how their pass/fail and coverage feed the UVM testbench, and how they complement the scoreboard and coverage.

SVA integration is adding a concurrent, signal-level, temporal-checking layer to the UVM environment. An assertion is a continuously-evaluated rule about signal behavior over time (a property — a temporal sequence over clock cycles, assert property) that fires on violation — always watching, concurrently, every cycle. Assertions live in the interface (natural for protocol rules on the interface signals) or, most powerfully for DV, in a separate checker module bind-ed to the DUT — attaching to the DUT's signals without modifying the RTL. Integration with UVM is two-way: assertion failures route into the UVM report server (so a firing assertion fails the UVM test and is counted with UVM errors — not just printed to the sim log), and assertion coverage (cover property) feeds the coverage picture (confirming the assertion's scenario was actually exercised, not vacuously passed). SVA complements the scoreboard (transaction-level correctness) and functional coverage (completeness): assertions catch protocol/timing bugs precisely and early (at the cycle and signal of the violation), the scoreboard catches data/functional bugs end-to-end, and coverage measures thoroughness — a layered strategy. This chapter is SVA integration: the layer, placement and bind, the UVM reporting/coverage feed, and the complement to scoreboard and coverage.

How does SVA integrate into a UVM environment — what is an assertion as a checking layer, where do assertions live and how does bind attach them non-intrusively, how do their failures and coverage feed the UVM testbench, and how does assertion-based checking complement the transaction-level scoreboard and functional coverage?

Motivation — why a transaction-level testbench needs assertions

The scoreboard-and-coverage machine is powerful but blind to a class of bugs. The reasons SVA is a needed complement:

• The transaction abstraction hides signal-level rules. The scoreboard compares assembled transactions — after the protocol has completed. It can't see the cycle-by-cycle rules during the transaction: handshake timing, signal stability, mutual exclusion. A violation of those is a real bug invisible to the transaction check.
• Assertions fire precisely, pinpointing the bug. An SVA fires at the exact cycle and signal where the rule broke — so debug is immediate (the waveform shows where and when), versus a scoreboard mismatch that surfaces later and requires tracing back to the root cause.
• Assertions are always-on and concurrent. They watch every cycle, concurrently, independent of the transaction flow — so they catch transient violations (a glitch, a one-cycle protocol break) that a transaction-level sampler might never observe.
• Assertions are local, self-documenting, and reusable. Each checks one protocol rule, independent of the rest; the property is the spec rule (self-documenting); and a protocol checker binds to any instance (reusable across blocks).
• But only if integrated. An assertion that $errors to the sim log but not the UVM report server leaves the UVM test reporting PASS despite a violation — so the integration (failures → UVM, coverage → the picture) is what makes assertions count in the regression.

The motivation, in one line: a transaction-level testbench is blind to the cycle-by-cycle protocol and timing rules on the signals — and those bugs are real — so SVA adds the complementary layer that watches the signals concurrently and fires precisely at a violation; but only if integrated (failures → UVM reporting, coverage → the picture) does a firing assertion actually fail the test and count toward closure.

Mental Model

Hold SVA as sentries posted on the signal lines — each enforcing one protocol rule, tripping the instant it's broken, while the scoreboard is the end-to-end auditor of the results:

A transaction-level scoreboard is an auditor who checks the final books: it takes the completed transaction's result and compares it to what the result should have been — end-to-end, after the fact. That catches wrong results, but it never watches the wires while the transaction is happening. SVA assertions are sentries posted directly on the protocol lines — each sentry enforces one specific rule (this signal must stay high until that one rises; this request must get a grant within three cycles; these two grants must never both be high), watches its line continuously, and trips an alarm the instant its rule is broken, at the exact wire and cycle. You post the sentries without disturbing the design — they tap the wires from outside (bind) — and you wire their alarms into the chain of command (UVM reporting), so a tripped sentry actually raises the alarm that fails the mission, not just a note in a logbook no one reads. The auditor and the sentries catch different things: the auditor catches a wrong final number; the sentries catch a protocol broken in the moment, precisely where and when it broke. Picture the verification as guarding a facility. The transaction-level scoreboard is an auditor who checks the final books — it takes the completed transaction's result and compares it to what the result should have been (end-to-end, after the fact). That catches wrong results, but the auditor never watches the wires while the transaction is happening. SVA assertions are sentries posted directly on the protocol lines — each sentry enforces one specific rule (this signal must stay high until that one rises; this request must get a grant within three cycles; these two grants must never both be high), watches its line continuously, and trips an alarm the instant its rule is broken, at the exact wire and cycle. You post the sentries without disturbing the design — they tap the wires from outside (bind — no RTL change) — and you wire their alarms into the chain of command (UVM reporting), so a tripped sentry actually raises the alarm that fails the mission, not just a note in a logbook no one reads (the unrouted-$error failure mode). The auditor and the sentries catch different things: the auditor catches a wrong final number (a data/functional bug, end-to-end); the sentries catch a protocol broken in the moment (a timing/handshake bug, precisely where and when it broke).

So SVA is sentries posted on the signal lines: each enforces one protocol rule, watches continuously, and trips precisely at the cycle and wire of a violation — posted non-intrusively (bind, no RTL change) and wired into the chain of command (UVM reporting, so a trip fails the test). The scoreboard is the end-to-end auditor (wrong results); the sentries are the protocol guards (rules broken in the moment); and coverage is the map of what's been guarded. Together they form a layered defense. Post sentries on the wires for the cycle-by-cycle rules, audit the books end-to-end for the results, and wire every alarm into the chain of command.

Visual Explanation — three complementary checking layers

The defining picture is the layering: SVA, the scoreboard, and functional coverage are three complementary layers watching the same DUT at different abstractions.

The figure shows the three complementary layers. SVA assertions (the brand-colored top — this module) watch the interface signals cycle-by-cycle, concurrently, checking protocol/timing rules and firing precisely at a violation. The scoreboard (Module 18) checks transaction-level correctness end-to-end — observed vs independently-computed expected — catching data/functional bugs. Functional coverage (Module 19) measures completeness — which scenarios were exercised. All three watch the same DUT (the bottom) at different abstractions. The crucial reading is that each operates at a different level and catches what the others miss: SVA sees the signals (cycle-by-cycle protocol — a handshake timing violation, a stability rule), the scoreboard sees the transactions (end-to-end data — a wrong result), and coverage sees the exercised scenarios (thoroughness — did we test enough). A protocol bug (VALID dropping before READY) is invisible to the scoreboard (whose transaction might still assemble correctly despite the protocol break, or fail later without pinpointing where) but caught precisely by SVA. A data bug (the DUT computed the wrong result despite correct protocol) is invisible to SVA (the protocol was fine) but caught by the scoreboard. So they're complementary — neither subsumes the other. The brand-colored SVA and the success-colored scoreboard are the checking layers (correctness, at different abstractions); the success-colored coverage is the measuring layer (completeness). This is why a mature verification environment has all three: SVA for signal-level protocol, scoreboard for transaction-level function, coverage for thoroughness — a layered strategy where each layer covers a blind spot of the others. The diagram is the defense in depth: three layers, three abstractions, three blind-spots covered — and this module adds the SVA layer to the scoreboard-and-coverage machine you already built. SVA, scoreboard, and coverage are complementary layers — signal-level protocol, transaction-level function, and completeness.

RTL / Simulation Perspective — bind and the UVM reporting hookup

In code, SVA integration is two concrete mechanisms: a checker module bind-ed to the DUT non-intrusively, and the failure action routed into UVM reporting. The example shows both.

// === 1. A CHECKER MODULE of protocol assertions — written by DV, separate from the RTL ===
module bus_protocol_checker(input logic clk, rst_n, req, ack, valid, ready);
 
  // a concurrent assertion: REQ must be granted (ACK) within 3 cycles
  property req_acked;
    @(posedge clk) disable iff (!rst_n) req |-> ##[1:3] ack;
  endproperty
  a_req_acked: assert property (req_acked)
    else uvm_report_error("SVA", "req not acked within 3 cycles", UVM_NONE, `__FILE__, `__LINE__);
  //          ^^^ FAILURE routed into UVM reporting — fails the UVM test, counted as a UVM error
 
  // a cover property: confirm the antecedent (req) actually occurred — assertion really CHECKED
  c_req_seen: cover property (@(posedge clk) req);   // feeds the coverage picture (not vacuous)
 
  // VALID must stay stable until READY
  a_valid_stable: assert property (@(posedge clk) disable iff (!rst_n) valid && !ready |-> ##1 valid)
    else uvm_report_error("SVA", "valid dropped before ready", UVM_NONE, `__FILE__, `__LINE__);
endmodule
 
// === 2. BIND the checker to the DUT — NON-INTRUSIVELY, no RTL change ===
bind dut_top bus_protocol_checker u_chk(.clk(clk), .rst_n(rst_n),
                                        .req(req), .ack(ack), .valid(valid), .ready(ready));
// the checker now watches the DUT's actual signals; UVM env connects to the same interface
 
// ✗ MISTAKE: `else $error(...)` only → prints to the SIM LOG but NOT the UVM report server
//   → UVM_ERROR count stays 0 → the UVM test reports PASS despite the assertion firing (DebugLab)

The code shows the two integration mechanisms. (1) The checker module (bus_protocol_checker) is DV-written, separate from the RTL, holding concurrent assertions: req_acked (REQ must get ACK within 3 cycles — req |-> ##[1:3] ack) and valid_stable (VALID stays stable until READY). Crucially, each assertion's else routes the failure into UVM reporting (uvm_report_error(...)) — so a firing assertion fails the UVM test and is counted as a UVM error, not merely printed. A cover property (c_req_seen) confirms the antecedent (req) actually occurred — so the assertion really checked (not vacuously passed), feeding the coverage picture. (2) The bind attaches the checker to the DUT (bind dut_top bus_protocol_checker u_chk(...)) — non-intrusively, no RTL change — so the checker watches the DUT's actual signals, and the UVM env connects to the same interface. The mistake (commented) is else $error(...) only — which prints to the sim log but not the UVM report server, so the UVM_ERROR count stays 0 and the UVM test reports PASS despite the assertion firing (the DebugLab). The shape to carry: SVA integration is (a) a bound checker module (assertions separate from RTL, attached non-intrusively via bind to the DUT's signals) and (b) failures routed into UVM (uvm_report_error in the assertion's else, not a bare $error) plus cover property feeding the coverage picture. The bind is what makes assertions DV-owned and non-intrusive — DV writes the protocol checker once and binds it to the DUT without touching the designer's RTL. The UVM-reporting hookup is what makes a firing assertion count — without it, the assertion is a sentry whose alarm goes to a logbook no one reads. Bind a separate checker to the DUT's signals, and route every assertion failure into UVM reporting.

Verification Perspective — what SVA catches that the scoreboard cannot

The integration pays off when SVA catches a protocol bug the scoreboard misses. Seeing what each catches — and where SVA's blind spot is — clarifies the complement.

The figure shows what each catches and how they complement. SVA (watching the signals, every cycle) catches protocol and timing violations: a handshake that misses its window, a signal that drops before it should, two grants asserted at once — pinpointed at the exact cycle. The scoreboard (comparing assembled transactions) catches functional data errors: a wrong result, a corrupted payload, a mis-ordered response — end-to-end. The crucial reading is the complementary blind spots: SVA's blind spot is functional correctness when the protocol is legal (the handshake was perfect, but the DUT computed the wrong answer — SVA sees nothing wrong); the scoreboard's blind spot is protocol violations that don't corrupt the final transaction (VALID glitched for a cycle, but the transaction still assembled correctly — the scoreboard sees nothing wrong, yet the protocol break is a real bug that would fail in a different context or a stricter DUT). So each covers the other's blind spot (the warning-colored complement): SVA catches the protocol bugs the scoreboard's abstraction hides, and the scoreboard catches the functional bugs SVA's protocol-only view misses. The brand-colored SVA and scoreboard, watching at different abstractions, produce the success-colored distinct catches, which combine into complementary coverage. This is the operational meaning of "complementary layers": you need both because neither is complete — a protocol-legal but functionally-wrong DUT passes SVA but fails the scoreboard; a functionally-right but protocol-violating DUT passes the scoreboard but fails SVA. The integration of SVA into UVM is what lets both run together on the same stimulus, each catching its class of bug. The diagram is the complement: SVA (protocol, pinpointed) + scoreboard (function, end-to-end) → each covers the other's blind spot — defense in depth across abstractions. SVA catches protocol broken in the moment; the scoreboard catches the wrong final result — run both.

Runtime / Execution Flow — an assertion from evaluation to UVM

At run time, a concurrent assertion goes through a fixed lifecycle every cycle — and the integration determines where its result goes. The flow shows it.

The flow shows the assertion lifecycle and where its result goes. Sample (step 1): the assertion samples its signals on the clock — concurrently, every cycle, independent of the transaction flow. Evaluate (step 2): when the antecedent triggers (e.g. req rises), the property evaluates over the following cycles (the temporal sequence — ##[1:3] ack). Result (step 3): the property holds (pass — and a cover property records the antecedent fired, so the check wasn't vacuous) or is violated (fail). Route (step 4): on failure, the integration matters — routed via uvm_error → fails the test, counted; a bare $error → sim log only, the UVM test still passes. The runtime insight is that the assertion's evaluation is automatic and concurrent (the simulator evaluates it every cycle), but where its failure goes is determined by the integration — and that is what makes or breaks its value in the regression. The same fired assertion either fails the regression (routed to UVM) or is silently missed (bare $error in a log no one greps) — a stark difference from one line of integration. This is why the UVM hookup (step 4) is the crux of integration: the checking (steps 1–3) is SVA's job (the simulator does it), but the consequence (step 4) is the integration's job (you route it). The cover property (step 3) is the other integration: it confirms the antecedent fired, so a "passing" assertion is known to have actually checked (not vacuously passed because the antecedent never occurred). The flow is the assertion's path: sample → evaluate → pass/fail → (routed to UVM, or lost to the log) — and the integration is steps 3–4: cover the antecedent (so passes are meaningful) and route failures to UVM (so fails count). The simulator evaluates the assertion; the integration decides whether a failure fails the test or is silently logged.

Waveform Perspective — an assertion firing at the exact violation

SVA's signature is temporal precision: the assertion evaluates a property over cycles and fires at the exact cycle the rule breaks. The waveform shows a passing case and a firing (violation) case.

The waveform shows the assertion's temporal precision. The property is: when req rises, ack must arrive within 3 cycles. In the first case, req rises and ack arrives 2 cycles later — the property holds (assert_pass). In the second case, req rises but ack never arrives within the window — at the 3rd cycle after req with no ack, the assertion fires (assert_fire) at exactly that cycle, pinpointing the violation. The crucial reading is the temporal evaluation and precise fire: the assertion starts evaluating when the antecedent (req) triggers (eval_window opens), watches the following cycles for the consequent (ack), and resolves — pass (ack came) or fire (window elapsed without ack), at the exact cycle the rule is satisfied or broken. The fire at cycle 10 is the signature of SVA: it points at the precise cycle (and the property names the signal/rule), so a verifier opening the waveform sees immediately where and when and which rule broke — no tracing back from a later symptom. This contrasts with a scoreboard mismatch, which surfaces after the transaction completes and requires working backward to find the cycle the bug originated. The picture to carry is that an assertion is a temporal property evaluated continuously, firing at the exact violation point — which is why SVA debug is immediate (the fire is the location) and why SVA catches transient, cycle-precise violations the transaction abstraction would blur. Reading the waveform this way — when did the property start, and did it hold or fire, and exactly where? — is reading an assertion. The fire at the precise window-expiry cycle is the signature of temporal checking: the rule, the signal, and the cycle, all pinpointed. An assertion evaluates a property over cycles and fires at the exact violation — the precise cycle and rule, which is what makes SVA debug immediate.

DebugLab — the assertion that fired into a passing test

✗ BARE $error — prints to the sim log, but NOT the UVM report server:
  a_valid_stable: assert property (...) else $error("valid dropped before ready");
  // the assertion FIRES → "Error: valid dropped..." in the SIM LOG
  // BUT: $error does NOT increment UVM_ERROR → regression checks UVM_ERROR==0 → reports PASS
  // the violation is flagged in ONE log among thousands, unread → ships as a "passing" test
 
✓ ROUTE the failure into UVM reporting — a firing assertion FAILS the UVM test:
  a_valid_stable: assert property (...)
    else `uvm_error("SVA", "valid dropped before ready")   // → increments UVM_ERROR
  // now the assertion firing makes UVM_ERROR > 0 → the UVM test reports FAIL
  // the regression flags it immediately, the night the bug appears → caught, not shipped
  // (alternatively: a global assertion-failure handler that calls uvm_error for every SVA failure)

Common Mistakes

• Leaving assertion failures as bare $error. They print to the sim log but don't increment UVM_ERROR, so the UVM test passes despite a firing assertion; route through uvm_error.
• Not covering the antecedent. A passing assertion may be vacuously passing (the antecedent never occurred); add cover property to confirm it actually checked.
• Modifying the RTL to add assertions. Use bind to attach a separate checker module non-intrusively, keeping DV assertions out of the designer's RTL.
• Treating SVA as a scoreboard replacement. SVA catches signal-level protocol bugs; the scoreboard catches end-to-end functional bugs — they're complementary, not substitutes.
• Binding to the wrong scope or mismatched signals. A bind that connects the wrong signals leaves the checker watching nothing useful; verify the binding against the DUT.
• Not testing the integration. Without forcing a known violation, you can't be sure a real failure fails the test; prove the path end-to-end.

Senior Design Review Notes

Interview Insights

Exercises

1. Route the failure. Rewrite an assertion whose else action is $error so that a firing assertion fails the UVM test.
2. Bind a checker. Sketch a checker module with one protocol assertion and the bind statement attaching it to a DUT non-intrusively.
3. Place the layers. For a wrong-result bug and a VALID-dropped-early bug, name which layer (SVA or scoreboard) catches each and why.
4. Avoid the vacuous pass. Explain why an all-passing assertion might have checked nothing, and what to add to confirm it checked.

Summary

• SVA integration adds a concurrent, signal-level, temporal-checking layer to the UVM environment — assertions are continuously-evaluated rules about signal behavior over time that fire precisely at the exact cycle and signal of a violation, complementing the transaction-level scoreboard and functional coverage.
• Assertions live in the interface or, for DV, in a separate checker module bind-ed to the DUT — attaching to the DUT's signals non-intrusively, without RTL changes, keeping the assertions DV-owned and reusable.
• Integration with UVM is two-way: assertion failures must route into the UVM report server (uvm_error, not a bare $error) so a firing assertion fails the UVM test and is counted; and cover property confirms the antecedent fired so a pass is a real check, not a vacuous one.
• SVA complements the scoreboard and coverage as layers at different abstractions: SVA catches cycle-by-cycle protocol/timing bugs (pinpointed), the scoreboard catches end-to-end functional data bugs, and coverage measures completeness — each covers the others' blind spots.
• The durable rule of thumb: add SVA as the signal-level protocol layer the transaction abstraction hides — bind a separate checker to the DUT non-intrusively, route every assertion failure through uvm_error so a firing assertion fails the UVM test (a bare $error only logs and the regression still passes), cover the antecedents so passes are meaningful, and treat SVA, the scoreboard, and coverage as complementary layers; a sentry's alarm only matters if it's wired into the chain of command.

Next — Protocol Assertions: with SVA integrated, the next chapter writes the assertions themselves — the SVA language for protocol checking: sequences and properties, the implication operators, temporal delays and repetition, and how to translate a protocol's rules (handshakes, stability, ordering, timing windows) into concurrent assertions that precisely capture the specification.