Difficulty: Easy · Puzzle 3 of 6 · Topic: Scoreboard Puzzles: Mismatch or Ordering Bug?
Scoreboard sees duplicate packets with changing fields, and old entries mutate in logs. Find why data appears to rewrite history.
class rsp_monitor extends uvm_component;
uvm_analysis_port #(txn) ap;
txn t;
virtual task run_phase(uvm_phase phase);
t = txn::type_id::create("t");
forever begin
sample_bus_into(t);
ap.write(t); // same handle every time
end
endtask
endclassAnalysis ports pass object handles, not value copies.
1) Print object handles/ids in scoreboard to confirm same pointer repeats.
2) Observe later sampling mutates previously queued entries.
3) Clone transaction before ap.write or allocate a new object each sample.
4) In scoreboard, optionally clone on receipt for defensive isolation.
5) Add checker that flags repeated handle reuse across writes.Answer: Bug: monitor publishes the same transaction handle repeatedly; subscribers see mutated duplicates. Fix: clone/new transaction per write boundary.
Checked by running the code in Verilator 5; the printed output supports the answer above. Plain-SV model of handle reuse: one object pushed three times shows the last value three times, a new object per sample keeps history.
Compare logic can look broken even though ingestion semantics are wrong.
Which side should own defensive cloning: producer, consumer, or both? Model answer: The producer should always publish a fresh object (it owns object identity). The consumer clones only when it stores or mutates the item beyond the write() call; doing both everywhere costs allocation for no benefit.
First I check whether the duplicates are real DUT traffic or a testbench artifact, by comparing handle values in the log. The root cause is that the monitor publishes the same transaction handle repeatedly, so subscribers see mutated duplicates. The compare logic only looks broken. I confirm it by printing the handle on each write, and the fix is to create or clone a new transaction at every write boundary.