Difficulty: Hard · Puzzle 6 of 6 · Topic: Clocking Block Puzzles
Identify which line introduces race potential and why monitor observations become inconsistent across runs.
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
endmoduleDirect signal assignment bypasses clocking block skew semantics.
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: The direct `vif.req = 1` line is race-prone. Mixed driving styles create inconsistent cycle alignment and flaky checks.
Teams adopt clocking blocks but accidentally bypass them in one helper task, reintroducing races.
How would you enforce cb-only driving at compile time in your interface API?