Difficulty: Medium · Puzzle 2 of 6 · Topic: Scoreboard Puzzles: Mismatch or Ordering Bug?
Scoreboard reports exactly one missing response per test, always at reset release. The DUT responds with zero latency, so the response is valid at the very first clock edge that sees rst_n high: clk : _/-\_/-\_/-\_/-\_ rst_n : 0 0 1 1 1 (high from edge 3) rsp_valid: 0 0 1 0 0 (valid when sampled at edge 3, the first edge that sees rst_n=1) Find why the monitor drops it.
// monitor: registers a delayed copy of reset
always @(posedge vif.clk)
rst_n_q <= vif.rst_n;
virtual task run_phase(uvm_phase phase);
forever begin
@(posedge vif.clk);
if (!rst_n_q) continue; // bug: the delayed reset still reads 0 at the first edge that sees rst_n=1
if (vif.rsp_valid)
rsp_ap.write(sample_rsp());
end
endtaskCompare the reset the monitor gates on with the reset the DUT saw.
1) Correlate the missing transaction time with the reset release edge (edge 3 in the waveform).
2) The DUT sees rst_n=1 from edge 3 and its zero-latency response is valid at edge 3. The monitor gates on rst_n_q, a registered copy that is still 0 at edge 3 (it becomes 1 only at edge 4). Verified in Verilator: with this waveform the delayed gate drops the response at edge 3, while gating on the same-edge rst_n captures it. A response one cycle later (edge 4) would NOT be dropped by a one-flop delay.
3) That one-cycle-late gating discards exactly the legal response sampled at the first post-reset edge (and would also let one cycle of reset-time garbage through at reset assertion).
4) Fix: gate with the same value the DUT used, sampled on the same clocking-block edge as the data (cb.rst_n && cb.rsp_valid), not a delayed copy. For requests that started in reset, drop by comparing the request start to the reset window rather than by adding a grace cycle.
5) Add a directed test with a response at the first edge after release (and one just before reset assertion).Answer: Bug: the monitor gates on a one-cycle-delayed copy of rst_n, so it discards the legal response sampled at the first edge that sees reset released. Fix: sample reset and data on the same edge (clocking block) and gate with that, or filter by whether the request started during reset; do not add a 'grace cycle' workaround.
Checked by running the code in Verilator 5 and Icarus Verilog 13; the printed output supports the answer above. Plain-SV model of the monitor gate: the one-cycle-delayed reset drops the first legal response, the same-edge reset keeps it. Plain-SV model of the monitor gate: the one-cycle-delayed reset drops the first legal response, the same-edge reset keeps it.
Teams blame the predictor or DUT queue depth, or paper over it with a one-cycle grace; the principled fix is to sample reset and data at the same point.
Would you solve this with clocking block skew, sampled reset, or a protocol-state machine in the monitor? Model answer: Clocking-block sampling of rst_n and data on the same edge is the baseline. A protocol state machine in the monitor (IDLE/IN_RESET/ACTIVE) is better when requests can be in flight across reset, because it can discard exactly the transactions that began in reset.
The missing item is the first one after reset, so I look at how the monitor gates on reset. The root cause is that the monitor uses a one-cycle-delayed copy of rst_n, so it discards the legal response sampled at the first edge that sees reset released. I confirm it by comparing the reset and data sampling edges in the waveform. The fix is to sample reset and data on the same edge with a clocking block and gate with that, not to add a grace cycle.