Fix a transaction copy whose nested payload is still shared with the original.
Hardware context: Snapshot copies of nested transaction and descriptor graphs. Repair a scoreboard copy that shares its nested payload with the monitor's reused transaction.
This is a Fix problem: the code in the editor has one realistic defect. Find it and fix it.
A monitor publishes each read to the scoreboard and then reuses its transaction object for the next burst. The scoreboard keeps a copy made with copy(), and the copy has its own ID and address. But the data beats live in a nested payload object, and every stored expectation shows the beats of the latest burst.
copy() must return a transaction that shares nothing with the original: changing a beat of either one must leave the other alone.
Signals in the timeline
| Signal | Width | Role |
|---|---|---|
id | 8 | input of each check |
action | 4 | input of each check |
Full specification
class beat_payload;
byte unsigned beats[4];
endclass
class read_txn;
int id;
bit [15:0] addr;
beat_payload payload;
function new(input int id = 0, input bit [15:0] addr = 0);
function read_txn copy();
endclass
Each case builds a transaction, copies it, then changes one side: a beat of the original, a beat of the copy, the original’s id and addr, or the original’s whole payload object. It reports the copy’s fields and beats, two beats of the original, and whether the copy and its payload are separate objects.
Examples
Example 1
The monitor reuses its payload- Input
id = 3, addr = 16'h1000, beats 11 22 33 44; then the original's beat 1 becomes EE
- Output
separate_object = yes, separate_payload = yes, copy_id = 3, copy_addr = 0x1000, copy_beats = 0x44332211, original_beat2 = 0x33, original_beat1 = 0xee
The copy must still hold 22 in beat 1 (copy_beats 0x44332211); only the original shows EE.
Example 2
The scoreboard writes its copy- Input
id = 5, addr = 16'h2004, beats AA BB CC DD; then the copy's beat 2 becomes 11
- Output
separate_object = yes, separate_payload = yes, copy_id = 5, copy_addr = 0x2004, copy_beats = 0xdd11bbaa, original_beat2 = 0xcc, original_beat1 = 0xbb
Beat 2 of the original must stay CC.
Example 3
The original moves on- Input
id = 7, addr = 16'h3008; then the original's id and addr change
- Output
separate_object = yes, separate_payload = yes, copy_id = 7, copy_addr = 0x3008, copy_beats = 0xd0c0b0a, original_beat2 = 0xc, original_beat1 = 0xb
The copy keeps id 7 and addr 3008: plain fields were always copied by value.
Constraints and contract
- The copy has the same id, addr and beats as the original at the moment of the call.
- No object is shared between the original and the copy.
- Keep the class and method names.
Hints
Hint 1
Run the first example. Which object did the write to the original’s beat land in, and which objects can reach it?
Hint 2
Copying a handle gives you a second name for the same object. Which handle inside the transaction is copied that way?
Hint 3
The copy needs its own payload object, filled with the same beat values. The constructor already makes a fresh payload for you.
What this judge verifies: The copy is checked with every kind of later change to the original or the copy, on 63 seeded transactions. Passing shows the copy shares no object with the original.
63 checks on Verilator · local server. Run the examples first, then check the full regression. The suite is local and inspectable. A passing result establishes the tested cases, not a proof for all possible inputs.
See all 7 steps and the final capstone