ASIC Point Explore

← Design Verification Interviews

Interview Question · Code Writing

Default Clocking and Default Disable Iff

L1 JuniorL2 Mid-Levelsvadefault clockingdisable iff

The interviewer asks

This checker module will hold twenty properties, each repeating the clock and the reset. Rewrite the boilerplate once.

systemverilog
module fifo_props(input logic clk, rst_n, push, pop, full, empty);
  // ... twenty properties, each written as
  // assert property (@(posedge clk) disable iff (!rst_n) push |-> !full) else errors++;
endmodule
Reveal the Model Answer

Declare default clocking @(posedge clk); endclocking and default disable iff (!rst_n); at the top of the module, then write each rule as assert property (push |-> !full) else errors++;. Every assertion in that module without its own clock or disable iff inherits them. An assertion that needs a different reset writes its own disable iff, which overrides the default.

Where the Defaults ReachOne checker module with both defaults at the top. Arrows show which assertions take them.
Where the Defaults ReachOne checker module with both defaults at the top. Arrows show which assertions take them. component default clocking @(posedge clk) component default disableiff (!rst_n) component Twentyassertions No clock or reset oftheir own: theyinherit both component One assertionwith its owndisable iff Its own clauseoverrides the default component An instance ofanother module Not covered: it usesits own defaults inheritedinheritedoverriddendoes not reach
Read the diagram as text
  • default clocking: @(posedge clk)
  • default disable iff: (!rst_n)
  • Twenty assertions: No clock or reset of their own: they inherit both
  • One assertion with its own disable iff: Its own clause overrides the default
  • An instance of another module: Not covered: it uses its own defaults
  • default clocking → Twenty assertions: inherited
  • default disable iff → Twenty assertions: inherited
  • default disable iff → One assertion with its own disable iff: overridden
  • default disable iff → An instance of another module: does not reach

Defaults apply inside the module that declares them. They never flow into instances of other modules.

Self-Check

Tick each key point you covered in your answer.

What Interviewers Listen For (Junior)

A good junior answer writes both defaults once and shortens each property to its logic.

Cross-Questions

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

WhyWhat IfProve ItBreak ItCompare

  1. Default Clocking and Default Disable Iff
  2. WhyWhy Defaults Follow the Source, Not the HierarchyL2 Mid-Level

    Why doesn't a default disable iff flow down through module instances the way a parameter override can?

    Reveal the Model Answer

    The default is part of the module's declaration and is resolved at compile time. So a module means the same thing wherever it is instantiated. If defaults flowed through instances, a reusable checker would change behaviour depending on who instantiated it. Each reusable module therefore declares its own defaults, usually from its own ports.

    Self-Check

    Tick each key point you covered in your answer.

    Missed Corner

    "Bind fixes this: a bound checker inherits the target module's defaults."

    A bound module is still an instance of a separately declared module; its assertions use the defaults declared in its own source.

    Source IEEE 1800-2017 §16.15

  3. Break ItA Bound Checker with No Default DisableL2 Mid-Level

    Break it: a checker module is bound into the DUT and declares no default disable iff. What happens during reset?

    Reveal the Model Answer

    The DUT module's default does not reach into the bound checker, because defaults are resolved in each module's own declaration. So the checker's properties have no disable. They are evaluated during reset and can fail on reset values. Give the checker a reset port and its own default disable iff.

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "bind puts the checker inside the DUT, so it inherits the DUT's defaults."

    bind only instantiates the checker in the DUT scope. Its properties still use the defaults of its own declaration.

    Source IEEE 1800-2017 §16.15

  4. CompareA Default vs a Reset Argument on Each PropertyL2 Mid-Level

    Compare a default disable iff with named properties that take the reset as a formal argument.

    Reveal the Model Answer

    The default is shortest when one reset governs the whole module. A property with formal arguments, such as property p_hold(clk, rst, v, r);, carries its clock and reset with it. You can reuse it in modules with other resets, or in a library package. Libraries usually use arguments; a block's own checker usually uses defaults.

    default disable iffReset as a property argument
    Shortest whenOne reset governs the whole moduleEach property may use a different reset
    Moves to another moduleNo; each module declares its ownYes; the property carries its reset
    Typical homeA block's own checkerA library package

    Self-Check

    Tick each key point you covered in your answer.

    Misconception

    "Formal arguments make properties slower to simulate."

    Arguments are substituted at compile time; the evaluated property is the same.

    Source IEEE 1800-2017 §16.8

  5. Break ItA Cycle Delay That Needs a Default ClockL2 Mid-Level

    You put if (en) assert property (req |-> ##2 gnt) else errors++; inside always @(posedge clk), and the compiler stops with an error about cycle delays. Why?

    log
    %Error: main.sv:14: Usage of cycle delays requires default clocking (IEEE 1800-2023 14.11)
    Reveal the Model Answer

    The standard infers the clock of a procedural concurrent assertion from the always block's event control, so the code is legal. Verilator 5.052 additionally demands a default clocking block for ## there, and also tests en at the wrong edge for multi-edge procedural rules. Move such rules out of the procedure as en && req |-> ##2 gnt, which is clearer anyway.

    Self-Check

    Tick each key point you covered in your answer.

    Tool as Truth

    "The error means procedural concurrent assertions are illegal."

    They are legal and the clock is inferred; the message reflects this tool's restriction.

    Source ASIC Point engine notes (Verilator 5.052 SVA probes), "A3/A5 forms" (procedural ##2 row)

  6. What IfWhich Reset Disables Which CheckerL3 Senior

    Asked if the block has more than one reset

    An SoC has a power-on reset, per-block soft resets and a warm reset that keeps some state. How do you choose the disable iff for each assertion?

    Reveal the Model Answer

    Disable each property with the reset that clears the state it talks about. A rule on a block's FIFO uses that block's reset, not the chip's. A warm reset must not disable rules about state that survives it. That state gets its own checks that it really survived. Write the mapping into the checker's parameters and review it with the design owner, because a too-broad disable silently hides checks.

    Self-Check

    Tick each key point you covered in your answer.

    What Interviewers Listen For (Senior)

    A good senior answer maps each rule to the reset that clears its state. It adds checks for state that must survive a warm reset, instead of disabling them.

    Wrong Altitude

    "Disable everything on any reset; it is the safe choice."

    It hides bugs in logic that should keep running, or keep state, across a partial reset. Those are classic reset escapes.

  7. Prove ItSolve 6.6.11: A Read-Channel Assertion SuiteSimulator-graded

    Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

    Open Problem 6.6.11

What People Get Wrong

Common wrong answers and why they fail. Run It shows the wrong belief failing on a real simulator.

Misconception

"A default disable iff in the top testbench applies to every assertion below it."

It covers its own module and nested declarations, not the instances of separately declared modules. In the twin the checker instance still fires during reset until it declares its own default.

Run It

tb declares a default disable iff and instantiates a separately declared checker module. Traffic arrives during reset.

RUNVerilator · simulator service
Edit the code, then run it

        
Expected: t=25 chk.a_ack failed with rst=1 FAIL: the default disable iff in tb did not reach the assertion inside the chk instance

        
        
      

      
See the Fix
module chk(input logic clk, rst, req, ack);
  default disable iff (rst);            // the fix: each checker module declares its own default
  a_ack: assert property (@(posedge clk) req |=> ack)
    else $display("t=%0t chk.a_ack failed with rst=%b", $time, rst);
endmodule
module tb;
  logic clk = 0, rst = 1, req = 0, ack = 0;
  always #5 clk = ~clk;
  default disable iff (rst);            // still applies to assertions written in tb
  chk u_chk(.*);
  initial begin
    @(negedge clk) req = 1;             // traffic while still in reset
    @(negedge clk) req = 0;
    @(negedge clk) rst = 0;
    repeat (2) @(negedge clk);
    $display("PASS: no checker fired during reset");
    $finish;
  end
endmodule

Prints: PASS: no checker fired during reset

    

  

    
Misconception

    
"With defaults, an assertion that writes its own disable iff gets both conditions."

    
An explicit disable iff replaces the default for that assertion; the conditions are not combined.

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

  

    
Spec Misquote

    
"Default clocking is a testbench feature, so assertions cannot use it."

    
A default clocking block gives its clock to concurrent assertions in its scope that do not name one. It also defines what ## means in procedural code.

    
Source IEEE 1800-2017 §14.12

  

    
Learn It, Then Prove It