Difficulty: Hard · Puzzle 4 of 6 · Topic: Event Scheduling Puzzles
Determine when ack becomes 1 and why the program drive appears one cycle late to DUT sequential logic.
module dut(input bit clk, input bit req, output bit ack);
always @(posedge clk) ack <= req;
endmodule
module top;
bit clk = 0;
bit req = 0;
bit ack;
dut u_dut(.clk(clk), .req(req), .ack(ack));
always #5 clk = ~clk;
program automatic tb;
initial begin
@(posedge clk);
req = 1;
$display("[%0t REACTIVE] drove req=1", $time);
@(posedge clk);
$display("[%0t REACTIVE] ack=%0b", $time, ack);
$finish;
end
endprogram
endmoduleProgram blocks execute in reactive after module active/NBA.
1) At t=5 posedge, DUT always executes before program and samples req=0.
2) Program then drives req=1 in reactive at t=5.
3) DUT cannot see that new req until next posedge at t=15.
4) At t=15, DUT sets ack<=1, and program prints ack=1 in reactive.Answer: ack becomes 1 at t=15, not t=5. The program drive occurs in reactive, after DUT sequential sampling for that edge.
Assuming @posedge in module and program are equivalent timing domains causes off-by-one-cycle bugs.
Would a clocking block with output skew be a safer replacement than direct req assignment here?