Why First Sample Sees Old grant

Puzzle

Difficulty: Medium · Puzzle 1 of 6 · Topic: Clocking Block Puzzles

Explain the two displayed grant values and why the first sample is stale despite driving req in the same cycle.

Code

interface arb_if(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;
  arb_if vif(clk);
  always #5 clk = ~clk;

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

  initial begin
    vif.req = 0;
    @(vif.cb);
    vif.cb.req <= 1;
    $display("[%0t] cb.grant=%0b", $time, vif.cb.grant);
    @(vif.cb);
    $display("[%0t] cb.grant=%0b", $time, vif.cb.grant);
    $finish;
  end
endmodule

Hint

input #1step samples before the edge; output #0 drives at event edge.

Step-by-step solution

1) First @(vif.cb) samples grant from just before the edge, still old 0.
2) req drive via cb output #0 happens at that edge.
3) DUT updates grant<=req in NBA for that edge.
4) Next @(vif.cb) then samples updated grant=1.

Answer

Answer: First print is grant=0 at t=5, second print is grant=1 at t=15. Sampling and driving are intentionally offset by skew.

Why candidates get it wrong

Treating cb sampling and driving as a single atomic action leads to off-by-one-cycle errors.

Interviewer follow-up

If input skew changed to #0, how would the first sampled grant change?

Related topics

• Back to Clocking Block Puzzles

• Concurrency & Timing Puzzles section