Transaction Reconstruction

Monitors · Module 13 · Page 13.2

The Engineering Problem

Passive observation (Module 13.1) established what a monitor does: it observes the pins and reconstructs what it sees into transactions, passively and independently. This chapter is the how of that reconstruction. The driver serialized a transaction onto the bus — it took a single transaction object and spread it across multiple cycles (address this cycle, data later, qualified by handshakes, Module 12.2). The monitor must do the exact inverse: take the multi-cycle pin activity and re-assemble it into a single transaction object. The hard part is that a transaction is not a single cycle — it has phases: the address appears at the address phase, the data appears (possibly several cycles) later, a burst spreads data across many beats. The monitor must collect each field at the cycle it actually appears, across the transaction's full duration, and emit the transaction only when it's complete. Sample everything in one cycle and you capture an address that's valid but data that isn't — a wrong transaction from correct pins.

Transaction reconstruction is the process by which the monitor deserializes pin-level activity back into a transaction. Where the driver unpacked a transaction into a timed sequence of pin values (serialization), the monitor re-packs that timed sequence back into a transaction (deserialization) — and to do it correctly, it must follow the protocol's framing: know which cycle each field appears on, collect it there, and assemble the complete transaction across the transaction's whole lifetime. This chapter is reconstruction's mechanics: the inverse-of-serialization model, the multi-cycle collection it requires, completeness and correctness, and the framing bug that produces a wrong transaction from a correct bus.

How does a monitor reconstruct a transaction from pin-level activity — collecting each field at the protocol cycle it appears, across the transaction's full multi-cycle duration, and emitting only when complete — as the inverse of the driver's serialization?

Motivation — why reconstruction is more than a single sample

Reconstruction looks like "read the pins into a transaction," but the timing makes it a genuine process. The reasons it's non-trivial:

• A transaction is multi-cycle. The driver spread the transaction across time — address at the address phase, data at the data phase (often later), a burst across many beats. So the fields don't all exist on the bus at once; the monitor must collect them across cycles.
• Each field has a valid cycle. A field is only meaningful on the bus during its phase (qualified by the handshake / valid). Sample data before its phase and you capture a stale or X value. The monitor must sample each field when it's valid, not all at one moment.
• Reconstruction is the inverse of serialization, so it needs the same protocol knowledge. The driver knew the framing to serialize (what to drive when, Module 12.2); the monitor needs the same framing to deserialize (what to sample when). Reconstruction is protocol-specific by nature.
• Completeness matters — emit only when whole. The scoreboard and coverage need all the fields. Emit a transaction before the last field arrives and you broadcast an incomplete transaction (a default/garbage field) → a false mismatch. The monitor must wait until the transaction is complete, then emit once.
• Bursts and multi-beat transfers extend the collection. A burst transaction has N data beats across N cycles; reconstruction must collect all beats into the transaction's data array — not just the first.

The motivation, in one line: reconstruction is non-trivial because the transaction lives across time, not in one cycle — the monitor must follow the protocol's framing to collect each field at its valid cycle, assemble the full transaction across its whole duration, and emit only when complete, which is exactly the inverse of how the driver serialized it.

Mental Model

Hold reconstruction as the deserializer mirroring the serializer:

The driver serialized the transaction onto the wire over time; the monitor deserializes it back — collecting each field as it arrives, in the protocol's framing, and assembling the whole before emitting. Picture a package being shipped over a conveyor belt. The sender (the driver) took a complete package (the transaction) and disassembled it into parts that travel the belt one after another — the label (address) goes first, the contents (data) follow several positions later, and a big order ships as many boxes in sequence (a burst). That's serialization: one object spread across the belt over time. The receiver (the monitor) stands at the end of the belt and must reassemble the original package: it catches the label as it passes, waits for the contents to arrive at their position, catches those, gathers all the boxes of a multi-box order — and only when the last box has passed does it hand over the reassembled package (emit the transaction). Two things make the receiver correct. It must know the belt's framing — which position each part rides on — so it catches each part at the right moment (catch the contents too early and you grab the previous order's contents). And it must wait for completeness — hand over the package only when whole, never a half-assembled box. The receiver is the mirror of the sender: the sender took apart and spread across the belt; the receiver catches across the belt and puts back together.

So reconstruction is deserialization mirroring serialization: the driver disassembled the transaction across time, the monitor reassembles it across time — catching each field at its framed position, gathering the whole, and emitting only when complete. The monitor needs the same protocol framing the driver used, run backwards: where the driver asked "what do I drive this cycle?", the monitor asks "what do I collect this cycle?" — and assembles the answer into a transaction.

Visual Explanation — reconstruction is the inverse of driving

The defining picture is the mirror: the driver serializes a transaction into timed pins; the monitor deserializes timed pins back into a transaction.

The figure shows reconstruction as serialization run backwards. On the driver side (Module 12.2), one transaction goes in, the driver serializes it — unpacking the single object into a timed pin sequence: the address driven at the address phase, the data at the data phase, the beats of a burst across successive cycles. The transaction has been spread across time on the bus. On the monitor side, the monitor does the inverse: it observes that same timed pin sequence and deserializes it — collecting each field at the cycle it appears and re-packing them into a reconstructed transaction. The crucial reading is the mirror symmetry: the driver and monitor are the same protocol framing run in opposite directions. The driver, knowing the framing, asks "what do I drive this cycle?" and spreads the transaction out; the monitor, knowing the same framing, asks "what do I collect this cycle?" and gathers it back. The warning-colored node in the middle — the timed pin sequence — is the shared artifact: it's what the driver produces and the monitor consumes, the common ground where the transaction exists as spread-out pin activity rather than as a single object. This is why reconstruction needs the protocol's framing: to reverse the serialization, the monitor must know the same thing the driver knew — which field rides which cycle — just applied to collecting instead of driving. The diagram is the conceptual heart of the chapter: reconstruction is not a fresh problem; it's the driver's serialization inverted, and a monitor that gets the framing right reassembles exactly the transaction the driver disassembled.

RTL / Simulation Perspective — the reconstruction collection

In code, reconstruction is a collection across cycles: sample the address at the address phase, wait for the data phase, sample the data there, then build and emit. The code shows the multi-cycle gather.

task run_phase(uvm_phase phase);
  forever begin
    bus_item tr = bus_item::type_id::create("tr");
 
    // --- ADDRESS PHASE: collect the address when it is valid ---
    @(posedge vif.clk iff (vif.valid && vif.is_addr_phase));
    tr.addr    = vif.addr;          // collect addr AT the address phase
    tr.is_read = vif.wr ? 0 : 1;
 
    // --- DATA PHASE: WAIT for it, then collect the data when IT is valid ---
    @(posedge vif.clk iff (vif.valid && vif.is_data_phase));
    tr.data    = vif.data;          // collect data AT the data phase (NOT the addr cycle)
 
    // --- BURST: collect all beats into the transaction's data array ---
    for (int i = 0; i < tr.len; i++) begin
      @(posedge vif.clk iff vif.beat_valid);
      tr.beats.push_back(vif.data); // gather every beat across its cycle
    end
 
    ap.write(tr);                   // EMIT only now — transaction is COMPLETE (13.4)
  end
  // ✗ sampling tr.data at the ADDRESS phase captures a stale/not-yet-valid value (DebugLab)
  // ✗ emitting before the data/burst is collected broadcasts an INCOMPLETE transaction
endtask

The code makes reconstruction's time structure explicit. The loop reconstructs one transaction per pass, and within a pass it moves through the transaction's phases in order. The address phase: @(posedge vif.clk iff (vif.valid && vif.is_addr_phase)) waits for the address phase, then tr.addr = vif.addr collects the address there — at the cycle it's valid. The data phase: a separate @(...) waits for the data phase (which may be cycles later), then tr.data = vif.data collects the data there — crucially, not at the address cycle, where data isn't valid yet. The burst: a loop gathers every beat (tr.beats.push_back(vif.data)) across its cycle, collecting all of a multi-beat transfer. Only after all phases are collected does ap.write(tr) emit — the transaction is complete. The two negative comments mark the traps: sampling data at the address phase captures a stale/not-yet-valid value (the DebugLab), and emitting before collection broadcasts an incomplete transaction. The shape to carry: reconstruction code walks the protocol's phases in time — one synchronization per phase, collecting each field where it's valid — and emits once, whole. It's structurally the mirror of the driver's serialization loop (Module 12.2), which drove each phase in turn; here the monitor collects each phase in turn.

Verification Perspective — completeness and correctness

A reconstructed transaction is only useful if it's complete (all fields the scoreboard needs) and correct (each field sampled at its valid cycle). Both follow from framing-aware collection.

The figure shows the two quality properties reconstruction must hold. Correctness — each field is collected at its valid phase: the address at the address phase, the data at the data phase, the burst beats across the beats (the warning-colored nodes mark where each field is valid — its phase). The monitor must sample each field at its phase, never before — a field sampled at the wrong phase captures a stale or not-yet-valid value, producing a wrong field. Completeness — all the fields are gathered into the assembled transaction: every field the scoreboard and coverage need, none omitted. Only when the transaction is both complete and correct does the monitor emit it (once, when whole). The verification stakes are direct: the scoreboard checks the reconstructed transaction against expected, so a wrong field (correctness failure) produces a false mismatch (the scoreboard flags a bug that isn't there — the pins were right, the reconstruction was wrong), and an incomplete transaction (completeness failure — a missing field left at its default) also produces a false mismatch or a missed check. Either way, reconstruction errors masquerade as DUT bugs — the most confusing kind of failure, because the DUT is innocent and the testbench is lying. This is why reconstruction must be framing-exact: the scoreboard trusts the reconstructed transaction as ground truth (Module 13.1), so the reconstruction must actually be ground truth — every field, correct, at its phase, complete. Get the framing right and the reconstruction is what happened; get it wrong and the testbench invents a discrepancy the silicon never had.

Runtime / Execution Flow — collect across phases, then emit

At run time, reconstruction walks the transaction's phases in order — synchronizing to each, collecting its field — and emits only after the last. The flow shows the phase walk.

The flow is reconstruction as a walk through time. Collect the address (step 1): synchronize to the address phase and sample the address where it's valid — the first field of the transaction's life. Collect the data (step 2): synchronize to the data phase — which may be several cycles later — and sample the data there, not at the address cycle (where data isn't valid yet). Collect the beats (step 3): for a burst, gather every beat across its cycle into the transaction's data array — the transaction isn't done until all beats are in. Emit when complete (step 4): only now, with every field collected, broadcast the transaction once (Module 13.4). The runtime insight is that reconstruction takes as long as the transaction takes — it's not an instant; it spans the transaction's whole duration, synchronizing to each phase in turn. This is precisely the driver's serialization loop (Module 12.2) run in reverse: where the driver waited for each phase and drove the field, the monitor waits for each phase and collects the field. The symmetry is exact — same phases, same framing, same number of synchronizations — just collect where the driver drove. And the emit-when-complete discipline mirrors the driver's done-when-the-last-phase-is-driven: the monitor emits exactly when the transaction is whole, the same moment the driver would consider the transaction finished. The flow is reconstruction living through the transaction's lifetime, phase by phase, gathering as it goes, and handing over the assembled transaction at the end.

Waveform Perspective — collecting fields across cycles

Reconstruction's multi-cycle nature is visible on a timeline: the address appears at one cycle, the data at a later cycle, and the monitor collects each at its phase, emitting the assembled transaction only at the end. The waveform shows the gather.

The waveform shows reconstruction spread across cycles. At the address phase (cycle 1), addr_phase asserts and addr carries 40; the monitor collects the address — collect_addr pulses there. Then, several cycles later, at the data phase (cycle 4), data_phase asserts and data carries C3; the monitor collects the data — collect_data pulses there, at the data phase, not at the address cycle. Only after both fields are collected does mon_emit pulse (cycle 5), broadcasting the complete reconstructed transaction (addr=40, data=C3). The crucial visual is the separation in time: the address and data are valid at different cycles, and the monitor's collect pulses line up with each field's phase — that alignment is correct reconstruction. The counterfactual is the bug: if the monitor sampled data at cycle 1 (the address cycle), data is still -- (not yet valid) — it would capture a stale/garbage value, producing a transaction with the wrong data field despite the bus being perfectly correct. Reading a waveform for reconstruction correctness — does each collect pulse line up with that field's valid phase? does emit happen only after the last field? — is how you verify the monitor is gathering the transaction correctly across its duration. The picture to carry: reconstruction is visible as collect-pulses marching across the transaction's phases, each aligned to where its field is valid, with the emit at the end — the transaction assembled across time, not snapped in one cycle.

DebugLab — the wrong transaction from a correct bus

✗ sampling ALL fields in one cycle (treating a multi-cycle transaction as single-cycle):
  @(posedge vif.clk iff vif.valid);   // the ADDRESS phase
  tr.addr = vif.addr;                 // ✓ addr is valid here → 40 (correct)
  tr.data = vif.data;                 // ✗ data is NOT valid yet → stale 00 (WRONG)
  ap.write(tr);                       // emits {addr=40, data=00} — wrong data, correct bus
 
✓ collect each field AT its phase (follow the protocol framing):
  @(posedge vif.clk iff (vif.valid && vif.is_addr_phase));
  tr.addr = vif.addr;                 // collect addr at the address phase
  @(posedge vif.clk iff (vif.valid && vif.is_data_phase));
  tr.data = vif.data;                 // collect data at the DATA phase → C3 (correct)
  ap.write(tr);                       // emits {addr=40, data=C3} — matches the bus

Common Mistakes

• Sampling all fields in one cycle. A multi-cycle transaction must be collected across phases; sampling everything at once captures fields before they're valid (stale/X).
• Sampling a field before its phase. Each field is valid only at its phase; sample it earlier and you capture a stale value — a wrong field from a correct bus.
• Emitting an incomplete transaction. Broadcasting before the last field (or burst beat) is collected sends a transaction with a default/garbage field — a false mismatch.
• Not mirroring the driver's framing. Reconstruction is serialization reversed; ignoring the protocol's phase structure makes reconstruction guess instead of follow.
• Dropping burst beats. A multi-beat transfer needs every beat collected; capturing only the first loses the rest of the data.
• Blaming the DUT for a reconstruction error. A correct bus with a wrong reconstructed field is a monitor bug, not a DUT bug — check the framing before the design.

Senior Design Review Notes

Interview Insights

Exercises

1. Trace the inverse. Given a driver that serializes a transaction as address-then-data, describe the monitor's reconstruction loop step by step.
2. Spot the framing bug. A monitor samples address and data in the same cycle. Explain what the data field will contain and why the scoreboard mismatches.
3. Reconstruct a burst. Sketch the collection loop for a 4-beat burst transaction, including where the emit goes.
4. Diagnose the innocent DUT. The scoreboard flags a data mismatch but the waveform shows the correct data at the data phase. Name the bug and the fix.

Summary

• Transaction reconstruction is the monitor deserializing pin-level activity back into a transaction — the inverse of the driver's serialization (Module 12.2): where the driver spread a transaction across cycles, the monitor gathers it back.
• A transaction is multi-cycle — fields don't all exist on the bus at once — so the monitor must collect each field at the protocol cycle it appears: the address at the address phase, the data at the data phase (often later), every burst beat across its cycle.
• Reconstruction needs the same protocol framing the driver used, run backwards: one synchronization per phase, collecting where the driver drove, and emitting only when the transaction is complete.
• A reconstructed transaction must be correct (each field sampled at its valid phase) and complete (all fields gathered) — a field sampled at the wrong phase captures a stale value, producing a wrong transaction from a correct bus that the scoreboard reports as a false DUT mismatch.
• The durable rule of thumb: reconstruct a transaction by collecting each field at the protocol cycle it appears — one synchronization per phase, mirroring the driver's framing — and emit only when complete; never sample every field in one cycle, because a field grabbed before its phase is stale, making the monitor invent a discrepancy the silicon never had.

Next — Protocol Monitoring: reconstruction assembles what happened into a transaction; protocol monitoring asks whether what happened was legal — the monitor as a protocol checker, watching the interface for handshake, ordering, and timing violations the DUT must never commit, and flagging them at the moment they occur.