Mixing Direct Drive and cb Drive

Puzzle

Difficulty: Hard · Puzzle 6 of 6 · Topic: Clocking Block Puzzles

Identify which line introduces race potential and why monitor observations become inconsistent across runs.

Code

interface ifc(input bit clk);
  logic req, grant;
  clocking cb @(posedge clk);
    default input #1step output #0;
    input grant;
    output req;
  endclocking
endinterface

module tb;
  bit clk = 0;
  ifc vif(clk);
  always #5 clk = ~clk;

  always @(posedge clk) vif.grant <= vif.req;

  initial begin
    @(posedge clk); vif.req = 1;      // direct net drive
    @(vif.cb);     vif.cb.req <= 0;  // clocking block drive
    repeat (2) @(vif.cb);
    $finish;
  end
endmodule

Hint

Direct signal assignment bypasses clocking block skew semantics.

Step-by-step solution

1) `vif.req = 1` on raw posedge is region-racy against DUT sampling.
2) `vif.cb.req <= 0` uses deterministic clocking block drive semantics.
3) Mixing both introduces inconsistent req capture by DUT across runs/tools.
4) Keep all interface drives through one clocking block discipline.

Answer

Answer: The direct `vif.req = 1` line is race-prone. Mixed driving styles create inconsistent cycle alignment and flaky checks.

Why candidates get it wrong

Teams adopt clocking blocks but accidentally bypass them in one helper task, reintroducing races.

Interviewer follow-up

How would you enforce cb-only driving at compile time in your interface API?

Related topics

• Back to Clocking Block Puzzles

• Concurrency & Timing Puzzles section