Immediate, Deferred and Concurrent Assertions

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfBreak ItCompareScale It

1. Immediate, Deferred and Concurrent Assertions
2. WhyWhy Deferred Assertions Were AddedL1 Junior

   Why did the standard add deferred assertions when immediate ones already existed?

   Reveal the Model Answer

   A combinational block can run several times in one time step while its inputs settle. An immediate check reports every in-between value. A deferred check waits until later in the time step. If the block runs again first, the pending report is dropped, so only the settled value counts. It gives procedural code, including functions, a glitch-free check without needing a clock.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 A combinational block can run several times in one time step while its inputs settle. Key point 2 An immediate check reports every in-between value. Key point 3 A deferred check waits until later in the time step. Key point 4 If the block runs again first, the pending report is dropped, so only the settled value counts. Key point 5 It gives procedural code, including functions, a glitch-free check without needing a clock.

   Misconception

   "Deferred means the check uses the values at the end of the time step."

   The expression is evaluated when the statement executes; only the report is delayed, and a re-run of the process replaces it.

   Source Mehta, SystemVerilog Assertions and Functional Coverage (3rd ed.), §5.1 (PDF p71)

   • Lesson A1.1Why Assertions
3. Break ItA Deferred Assertion That Still Fired on a GlitchL2 Mid-Level

   Your assert final (a == b) in always @(a or b) reports a mismatch at 10 ns. The waveform shows a and b equal by the end of that time step. Is the RTL wrong?

   t=10 assert final failed: a=1 b=0
   (wave at t=10, end of step: a=1 b=1)

   Reveal the Model Answer

   Not necessarily. The standard says the block's second run in that time step flushes the pending report, so no failure should appear. Some simulators, Verilator 5.052 among them, do not implement the flush and report the transient value. Confirm on another simulator, or move the rule to a clocked concurrent assertion that no simulator disagrees on.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Not necessarily. Key point 2 The standard says the block's second run in that time step flushes the pending report, so no failure should appear. Key point 3 Some simulators, Verilator 5.052 among them, do not implement the flush and report the transient value. Key point 4 Confirm on another simulator, or move the rule to a clocked concurrent assertion that no simulator disagrees on.

   Tool as Truth

   "The simulator reported it, so the design glitched in a way that matters."

   A zero-time glitch between two blocking updates is not hardware behaviour. Whether you see it depends on whether the tool follows the flush rule.

   Source ASIC Point engine notes (Verilator 5.052 SVA probes), deferred assertion flush row

   • Lesson A1.1Why Assertions
4. CompareAssert #0 vs Assert FinalL1 JuniorL2 Mid-Level

   Compare assert #0 with assert final. When does the difference matter?

   Reveal the Model Answer

   Both evaluate when executed and both flush on a re-run. An observed deferred assertion (#0) matures in the Observed region and runs its action in the Reactive region. So its action can still change state in that time step. A final deferred assertion runs its action block in the Postponed region, after all activity, so the action may only report. Use final when even testbench reactions to the check must not cause further glitches.

   	assert #0 (observed deferred)	assert final
   Report matures in	Observed region	Postponed region
   Action block runs in	Reactive region	Postponed region
   Action may change state	Yes	No, it may only report
   Flushed if the block runs again in the time step	Yes	Yes

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Both evaluate when executed and both flush on a re-run. Key point 2 An observed deferred assertion (#0) matures in the Observed region and runs its action in the Reactive region. Key point 3 So its action can still change state in that time step. Key point 4 A final deferred assertion runs its action block in the Postponed region, after all activity, so the action may only report. Key point 5 Use final when even testbench reactions to the check must not cause further glitches.

   Misconception

   "assert final waits until the end of simulation."

   final here means the Postponed region of the current time step, not the final procedure at the end of the run.

   Source IEEE 1800-2017 §16.4

   • Lesson A1.1Why Assertions
5. What IfWaiting for a Property: ExpectL2 Mid-Level

   Asked if they mention a test waiting on a property

   What if a directed test wants to block until a sequence such as req ##[1:3] ack has happened, and fail if it does not?

   Reveal the Model Answer

   expect (@(posedge clk) req ##[1:3] ack) else ...; is a procedural statement that blocks the calling process until that one property attempt passes or fails. It is a single attempt started where the statement runs, unlike an assert property, which starts an attempt every clock. Verilator 5.052 rejects expect, so on that engine wait with an explicit bounded loop instead.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 expect (@(posedge clk) req ##[1:3] ack) else ...; is a procedural statement that blocks the calling process until that one property attempt passes or fails. Key point 2 It is a single attempt started where the statement runs, unlike an assert property, which starts an attempt every clock. Key point 3 Verilator 5.052 rejects expect, so on that engine wait with an explicit bounded loop instead.

   Misconception

   "expect is the same as an assert property inside an initial block."

   An assert property placed in a procedure is queued and does not block the process. expect blocks until its single attempt completes.

   Source IEEE 1800-2017 §16.17

   • Lesson A5.1Assertions in Procedures, Sequences as Events
6. Scale ItWhich Assertions Formal Tools Can UseL3 Senior

   Your team writes many immediate assertions inside testbench classes. A formal lead asks to reuse the block's checks. What do you change?

   Reveal the Model Answer

   Formal tools work on the design and its bound checkers, not on class-based testbench code. Checks inside class methods cannot be reused there. Rewrite the interface rules as concurrent properties over DUT signals, in a checker module you can bind. Leave only transaction-level checks in the classes. The same file then runs in simulation as assertions and in formal as proof targets, with the input rules switched to assumptions.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Formal tools work on the design and its bound checkers, not on class-based testbench code. Key point 2 Checks inside class methods cannot be reused there. Key point 3 Rewrite the interface rules as concurrent properties over DUT signals, in a checker module you can bind. Key point 4 Leave only transaction-level checks in the classes. Key point 5 The same file then runs in simulation as assertions and in formal as proof targets, with the input rules switched to assumptions.

   What Interviewers Listen For (Senior)

   A good senior answer splits rules on signals from checks on transactions. Signal rules are bound and shared with formal; transaction checks stay in classes. It also switches input rules from assert to assume.

   Misconception

   "Formal can read any assertion in the testbench."

   Formal analyses synthesizable design logic plus properties over it; dynamic class objects and procedural testbench code are outside that model.

   Source Lesson A7.1 review claims (bind; checkers outside the RTL)

   • Lesson A7.1Packaging and Binding
   • Lesson F1.1Simulation Covers Paths, Formal Covers States