Assertoff, Assertkill and Disable Iff

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

WhyWhat IfCompareScale It

1. Assertoff, Assertkill and Disable Iff
2. CompareWhat Happens to the Attempt Already RunningL2 Mid-Level

   Compare $assertoff and $assertkill for an attempt that started two cycles before the call and is still waiting for its consequent.

   Reveal the Model Answer

   With $assertoff that attempt runs to completion and can still fail; only attempts that would start later are suppressed. With $assertkill it is aborted at once and reports nothing. Use $assertkill when the scenario that started those attempts has become meaningless, for example after an injected error.

   	$assertoff	$assertkill
   New attempts	Not started	Not started
   An attempt already running	Runs to the end and can still fail	Aborted at once; reports nothing
   Use it when	Running attempts are still meaningful	The scenario behind them is now meaningless

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 With $assertoff that attempt runs to completion and can still fail; only attempts that would start later are suppressed. Key point 2 With $assertkill it is aborted at once and reports nothing. Key point 3 Use $assertkill when the scenario that started those attempts has become meaningless, for example after an injected error.

   Misconception

   "$asserton resumes the attempts that $assertkill stopped."

   Killed attempts are gone. $asserton lets new attempts start at the following clock ticks.

   Source IEEE 1800-2017 §20.12

   • Lesson A3.5Reset and Abort: disable iff, Accept and Reject
3. What IfAssertions During an Error-Injection TestL2 Mid-Level

   Asked if they mention error-injection tests

   What if a test deliberately corrupts a CRC to check the error path? Write the control around the injection so only the right checks are switched off.

   Reveal the Model Answer

   Switch off only the checker instance that would fire on the injected error, with a scoped call such as $assertkill(0, tb.dut.rx.u_crc_chk). Inject the error, wait for the error path to finish, then call $asserton(0, tb.dut.rx.u_crc_chk). Keep the error-response checks on, since they are what the test is for, and log both calls.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Switch off only the checker instance that would fire on the injected error, with a scoped call such as $assertkill(0, tb.dut.rx.u_crc_chk). Key point 2 Inject the error, wait for the error path to finish, then call $asserton(0, tb.dut.rx.u_crc_chk). Key point 3 Keep the error-response checks on, since they are what the test is for, and log both calls.

   Missed Corner

   Calls $assertoff; with no arguments for the whole test.

   That disables every assertion in the design, including the ones that check the error response, for the rest of the run.

   Source IEEE 1800-2017 §20.12

   • Lesson A3.5Reset and Abort: disable iff, Accept and Reject
4. WhyWhy Assertion Control Lives in the TestL1 Junior

   If properties can describe their own exceptions, why does the language also give the test switches?

   Reveal the Model Answer

   Some exceptions depend on what the test is doing, not on design signals. Examples are an injected fault, a power-aware run with a domain switched off, or a bring-up test that runs before configuration. Encoding those in every property would couple checkers to tests. Control tasks keep the checker generic and put the test-specific decision in the test.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Some exceptions depend on what the test is doing, not on design signals. Key point 2 Examples are an injected fault, a power-aware run with a domain switched off, or a bring-up test that runs before configuration. Key point 3 Encoding those in every property would couple checkers to tests. Key point 4 Control tasks keep the checker generic and put the test-specific decision in the test.

   Half-Truth

   "Control tasks are a debugging convenience only."

   They are a standard part of assertion methodology for scenarios the properties cannot observe.

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

   • Lesson A3.5Reset and Abort: disable iff, Accept and Reject
5. What IfAn Assertoff That Was Never UndoneL1 JuniorL2 Mid-Level

   What if the test calls $assertoff for an error injection and never calls $asserton again?

   Reveal the Model Answer

   The rest of the test then runs with those checks off, and it still passes. Scope the call to the assertions the fault affects and to the window it lasts. Turn them back on with $asserton at a known point. Log both calls, so a review can see what was off and when.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The rest of the test then runs with those checks off, and it still passes. Key point 2 Scope the call to the assertions the fault affects and to the window it lasts. Key point 3 Turn them back on with $asserton at a known point. Key point 4 Log both calls, so a review can see what was off and when.

   Missed Corner

   "$assertoff is harmless; the next test starts fresh."

   Within this test it stays in force until $asserton. Bugs after the injection window then pass without a check.

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

   • Lesson A3.5Reset and Abort: disable iff, Accept and Reject
6. Scale ItA Regression Policy for Suppressed AssertionsL3 SeniorL4 Staff

   In a large regression, how do you stop assertion suppression from quietly hiding bugs?

   Reveal the Model Answer

   Route all control through one testbench utility that logs each call with its scope and time. Fail the test if any scope is still off at the end. Report per test which checkers were suppressed and for how long, and review that list like waivers. Prefer fixing an over-strict property to suppressing it.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Route all control through one testbench utility that logs each call with its scope and time. Key point 2 Fail the test if any scope is still off at the end. Key point 3 Report per test which checkers were suppressed and for how long, and review that list like waivers. Key point 4 Prefer fixing an over-strict property to suppressing it.

   What Interviewers Listen For (Staff)

   A good staff answer makes every switch-off auditable: logged, scoped, switched back on and reviewed. It treats a growing list of switched-off checks as a sign of weak properties.

   Wrong Altitude

   "Each test owner manages their own $assertoff calls."

   Unreviewed, unscoped calls accumulate, and a single forgotten one disables checking for every following phase of a test.

   • Lesson A8.1Capstone: An Assertion Suite