Transaction Conversion

Drivers · Module 12 · Page 12.2

The Engineering Problem

The previous chapter established the driver's one real job: convert a transaction into pin-level activity (Module 12.1). This chapter is that conversion in depth — because it's where the driver's entire protocol knowledge lives, and where the subtle bugs are. A transaction is logical ("a read of address 0x40, length 4"); the pins are physical (which signal carries the address, when the strobe asserts, how the data beats are clocked, how the handshake completes). The conversion is the mapping between them — and it's two-directional: a write drives signals out, but a read also samples the returned data back in. Forget half of that, and the testbench drives correctly but loses the read result.

Transaction conversion is the driver's mapping of a transaction's logical fields to the protocol's pin-level signaling — a procedural routine that drives each field onto its signal(s) in the protocol's order and handshake (addr → address bus, is_read → control, data[] → data beats), expanding one transaction into the multiple pin cycles the protocol requires (Module 8.1's one-to-many). For reads, it also samples the DUT's returned data back into the transaction's response field. The conversion is the single place the protocol's encoding lives — so it's protocol-specific, while everything else stays protocol-agnostic. This chapter is the conversion: the field-to-signal mapping, the procedural structure, the one-to-many expansion, and the read sampling that's easy to forget.

How does a driver convert a transaction into pin-level signaling — mapping each field to its signals in the protocol's order, expanding one transaction into many cycles, and (for reads) sampling the returned data back into the transaction's response?

Motivation — why conversion is the driver's core

Conversion is the driver's essence because it's where the logical-to-physical translation happens, and each of its properties follows from that:

• The transaction is logical and the pins are physical, so a mapping is required. A transaction says what ("read 0x40"); the pins need how (drive the address bus, assert the read strobe, clock the data). Bridging requires a mapping from each logical field to its physical signal(s) — there's no automatic correspondence.
• The protocol defines the signaling, so the conversion is the protocol encoding. How a logical operation appears on the wires is the protocol — the signal order, the handshake, the timing. The conversion encodes the transaction into that protocol, so the conversion is where the protocol lives in the testbench.
• One operation spans many cycles, so the conversion is procedural and time-consuming. A burst read is one transaction but many clock cycles of signaling (Module 8.1). So the conversion is a task that unfolds over time — driving across clock edges, looping over beats, waiting for handshakes — not a single assignment.
• Reads return data, so the conversion is two-directional. A write only drives out; a read drives the request out and samples the response in — capturing the DUT's returned data into the transaction's response field. So conversion isn't just "drive"; for reads it's "drive and sample."
• The protocol is isolated here, so everything else stays protocol-agnostic. Because the conversion is the only place the protocol's signaling lives, the transaction, the sequence, the scoreboard are all protocol-independent — a different protocol means a different conversion, and nothing else changes (the reuse argument).

The motivation, in one line: conversion is the driver's core because it's the logical-to-physical translation — a procedural, protocol-encoding, two-directional mapping (drive out, sample in) that expands one transaction into the protocol's many cycles — and isolating it in the driver is what keeps the rest of the testbench protocol-agnostic.

Mental Model

Hold transaction conversion as performing a transaction as the protocol's musical score:

Conversion is performing a transaction as the protocol's score: each field is a note, the protocol is the score's rules — which instrument plays it, when, with what rests and cues — and the performance expands one written phrase into the full passage the score demands, including listening for the response. The transaction is the written phrase (the meaning — "read 0x40"); the protocol is the score's notation (how that phrase is played — the address goes on this staff, the strobe is this cue, the beats are these notes, the handshake is waiting for the downbeat). The conversion is the performance: it takes each field (note) and plays it on the right instrument at the right moment (drives each field onto its signal in the protocol's order), and it expands the single phrase into the full passage — a burst read isn't one note but a measure of address, beats, and handshakes. And for a read, the performance is a duet: the driver plays its part (drives the request) and listens for the response (samples the returned data), capturing what comes back. A performer who played the notes but didn't listen for the response would miss the answer — exactly the read that drives but doesn't sample.

So conversion is playing the transaction by the protocol's rules: map each field to its signal in the right order, expand the one operation into the full multi-cycle passage, and — for reads — listen back, sampling the response. The protocol is the score; the conversion is the faithful performance, including the listening.

Visual Explanation — the field-to-signal mapping

The defining picture is the mapping: each of the transaction's logical fields drives one or more of the protocol's signals — the correspondence the conversion encodes.

The figure shows the correspondence that is the conversion. On the out direction (top), each logical field drives protocol signals: tr.addr → the address bus, tr.is_read → the read/write control, tr.data[] → the data beats (for a write). The len field (not shown as a node but implied) determines how many beats — so it controls the expansion (Module 8.1). On the in direction (bottom), for a read, the DUT's returned data (sampled from the pins) flows back into tr.rdata (the response field) — the conversion fills it from what it sampled. So the conversion is bidirectional: fields → signals (drive) and sampled data → response field (capture). The crucial reading is that this mapping is protocol-specific and owned by the driver: which field goes to which signal, in what order, is the protocol's encoding, and it lives here and nowhere else. Everything to the left (the transaction's fields) is protocol-agnostic — the sequence and scoreboard see logical fields, not signals. So the driver's conversion is the translation table between the two worlds, made procedural (driven over clock cycles in the protocol's order). The diagram is the conversion's content in one picture: a field-to-signal mapping in the drive direction, and a sampled-data-to-response mapping in the read direction — the complete, two-way correspondence the driver encodes.

RTL / Simulation Perspective — the conversion routine, write and read

The conversion is a procedural routine — typically branching on the operation, driving the request, and (for reads) sampling the response. The code shows both directions.

task my_driver::drive_transaction(bus_item tr);
  @(posedge vif.clk);
  vif.addr  <= tr.addr;                 // map addr → address bus
  vif.wr    <= !tr.is_read;             // map is_read → control
  vif.valid <= 1;
 
  if (!tr.is_read) begin
    // ── WRITE: drive the data beats OUT (one per beat — the expansion) ──
    foreach (tr.data[i]) begin
      vif.wdata <= tr.data[i];          // map data[i] → data beat
      @(posedge vif.clk iff vif.ready); // handshake: wait for ready each beat
    end
  end else begin
    // ── READ: drive the request, then SAMPLE the returned data back IN ──
    @(posedge vif.clk iff vif.ready);   // wait for the data phase (protocol's read latency)
    foreach (tr.data[i]) begin
      tr.rdata[i] = vif.rdata;          // ← SAMPLE the DUT's read data INTO the response field
      @(posedge vif.clk);
    end
  end
  vif.valid <= 0;                        // de-assert; drive idle between transactions
endtask
// ✗ a READ that drives the request but never samples vif.rdata → loses the read result (DebugLab)

The routine is the conversion made concrete, and it shows the two directions. The common part maps the request fields: tr.addr → vif.addr, tr.is_read → vif.wr, and asserts valid — driving each logical field onto its protocol signal, on a clock edge (the protocol's timing, drilled in Module 12.4). Then the routine branches on the operation. For a write, it drives the data beats out: foreach (tr.data[i]) drives tr.data[i] → vif.wdata, one per beat, waiting for ready each beat (the handshake) — this foreach is the one-to-many expansion (one transaction, len beats, Module 8.1). For a read, it's two-directional: it drives the request (already done) and then samples the response — foreach captures vif.rdata into tr.rdata[i] (the response field), one beat per cycle, at the protocol's read latency. The tr.rdata[i] = vif.rdata line is the critical read step — sampling the DUT's data back into the transaction — and the final comment flags the bug: a read that drives the request but never samples vif.rdata loses the read result (the DebugLab). After driving, the routine de-asserts and drives idle between transactions. The shape to carry: the conversion maps request fields out (always), expands data beats (the foreach), and — for reads — samples the response back in (tr.rdata = vif.rdata); the sampled data is then returned (via item_done(rsp), Module 11.3) to the sequence and scoreboard.

Verification Perspective — the conversion is the protocol encoding

The conversion's role is to be the single, isolated place the protocol's encoding lives — which is what keeps the rest of the testbench protocol-agnostic. Seeing this isolation is seeing why conversion matters beyond the driver.

The conversion's isolation of the protocol is the verification-architecture payoff. The transaction, sequence, and scoreboard all work in protocol-agnostic, logical terms — they deal in fields ("addr 0x40, read") and operations, never in signals or timing. The driver's conversion is the only place that knows the protocol's signaling — which field is which signal, the handshake, the timing (the protocol encoding). So the conversion is a firewall: the protocol is contained inside it, and everything outside is protocol-independent. The consequence is reuse across protocols: change the protocol (a different bus, a different framing) and you rewrite only the conversion — the same transactions, the same sequences, the same scoreboard all carry over, because none of them ever touched the protocol. This is the deeper reason the conversion is the driver's core (Module 12.1's "the driver is the translation point"): it's not just that someone must drive the pins; it's that isolating the protocol in one routine is what makes the expensive, reusable parts (stimulus, checking) protocol-agnostic and therefore portable. The verification skill is to keep the protocol entirely inside the conversion: no signal knowledge should leak into the sequence (it deals in fields) or the scoreboard (it compares fields). When the protocol is cleanly isolated in the conversion, the testbench reuses; when it leaks, reuse breaks (the same lesson as layered sequences, Module 10.2, applied to the pin boundary). The conversion is the protocol's container, and its cleanliness is what the rest of the testbench's portability rests on.

Runtime / Execution Flow — the procedural conversion, including sampling

At run time, the conversion unfolds procedurally over clock cycles: drive the request, run the handshake, expand the beats, and — for reads — sample the response. The flow shows the steps, including the read sampling that completes the round trip.

The procedural flow shows the conversion's time-unfolding structure and its two directions. Drive the request (step 1): map the request fields — addr → address bus, is_read → control — and assert valid, on a clock edge (synchronous driving). This is common to both operations. Then branch. For a write (step 2a): loop driving each data beat out — data[i] → the data signal — waiting for the handshake (ready) each beat, so the driver paces to the DUT (back-pressure, Module 8.3); the loop is the one-to-many expansion. For a read (step 2b): wait the protocol's read latency, then loop sampling each returned data beat in — vif.rdata → tr.rdata[i] (the response field) — capturing the DUT's data into the transaction. Complete (step 3): de-assert valid and drive idle; for a read, the captured response is returned to the sequence (via item_done(rsp), Module 11.3) and on to the scoreboard. The runtime insight is the asymmetry: a write is drive-only (data goes out), but a read is drive-and-sample (the request goes out, the data comes back in) — so the read flow has an extra, essential step (sampling) that the write doesn't, and it's the step most easily forgotten. The conversion's correctness depends on both directions being right: driving the request signals in the protocol's order and (for reads) sampling the response at the protocol's latency. Miss the drive and the DUT gets wrong signaling; miss the sample and the read result is lost (the DebugLab) — both are conversion failures, and the read-sampling one is the subtle one because the driving looks correct.

Waveform Perspective — a write and a read converted to pins

The conversion's two directions are clearest on a timeline: a write drives data out, while a read drives the request and samples data in — the same routine, two directions.

The waveform shows the conversion's two directions side by side. For the WRITE (left), the driver maps the transaction onto the pins: addr is driven to 0x40, wr is high, and the wdata beats W0, W1 are driven out — the data flows from the transaction to the DUT, the out direction. For the READ (right), the driver first drives the request (addr to 0x8C, wr low) — the request out — and then the DUT returns data on rdata (R0, R1), which the driver samples in: the sample markers show the driver capturing rdata into the transaction's response field, the in direction. So the same conversion routine produces two different pin behaviors depending on the operation: a write drives data out, a read drives a request and samples data in. The crucial visual is the read's rdata being sampled — that is the step that captures the read result; without it, the rdata signal would carry correct data on the pins but never reach the transaction, so the scoreboard would see nothing (the DebugLab). The picture to carry is the asymmetry made visible: writes are one-directional (transaction → pins), reads are two-directional (request → pins, data → transaction), and the conversion owns both — driving the request fields onto their signals and, for reads, sampling the response back, at the protocol's timing. The waveform is the conversion's behavior, and reading it — which signals carry which fields, when data is driven vs sampled — is how you verify a conversion is correct in both directions.

DebugLab — the read that drove correctly but lost its data

read conversion (BROKEN):
  vif.addr <= tr.addr;  vif.wr <= 0;  vif.valid <= 1;   // drive the request (correct)
  @(posedge vif.clk iff vif.ready);
  // ✗ MISSING: tr.rdata = vif.rdata;   ← never SAMPLES the DUT's returned data
  item_done(rsp);                                        // returns a response with DEFAULT rdata
 
on the pins:  DUT returns correct data on vif.rdata  ✓
in the txn:   tr.rdata never assigned → stays DEFAULT  ✗
→ scoreboard checks tr.rdata (default/stale), NOT the real DUT data → mismatch
 
fix — SAMPLE the returned data into the response field (at the protocol's read latency):
  @(posedge vif.clk iff vif.ready);
  tr.rdata = vif.rdata;        // ✓ capture the DUT's read data INTO the transaction
  // (multi-beat: foreach (tr.data[i]) begin tr.rdata[i] = vif.rdata; @(posedge vif.clk); end)
  rsp.set_id_info(tr);  item_done(rsp);   // return the response carrying the sampled data

Common Mistakes

• Forgetting to sample read data into the response. The read drives correctly but the transaction's rdata stays default; sample vif.rdata into the response field at the protocol's latency.
• Sampling read data at the wrong cycle. Capturing before the data is valid (or after it changes) gets garbage; sample at the protocol's read latency (Module 12.4).
• Mis-mapping a field to the wrong signal. Driving addr onto the data bus (or similar) sends wrong signaling; map each field to its correct protocol signal.
• Wrong beat count in the expansion. Driving len-1 or len+1 beats mis-sizes a burst; loop exactly over the transaction's beats.
• Letting protocol knowledge leak out of the conversion. Signal/timing logic in the sequence or scoreboard breaks protocol-agnosticism; keep the protocol entirely in the conversion.
• Ignoring the handshake. Driving beats without waiting for ready races the DUT; honor the protocol's handshake each beat.

Senior Design Review Notes

Interview Insights

Exercises

1. Map the fields. For a bus transaction with addr, is_read, data[], and len, state which protocol signal(s) each field drives, and which field the read data is sampled into.
2. Fix the read. Given a read conversion that drives the request but the scoreboard sees default data, identify the missing step and write it.
3. Expand the burst. Explain how a length-4 burst transaction becomes multiple pin cycles, and where the loop is in the conversion.
4. Defend the isolation. Explain why keeping the protocol only in the conversion lets the same sequences and scoreboard reuse across protocols.

Summary

• Transaction conversion is the driver's mapping of a transaction's logical fields to the protocol's pin-level signaling — a procedural routine that drives each field onto its signal(s) in the protocol's order and handshake, expanding one transaction into the many pin cycles the protocol requires.
• Each field maps to signals: addr → address bus, is_read → control, data[] → data beats, len → beat count — and the conversion is the single place this protocol encoding lives.
• Conversion is two-directional: a write drives data out, but a read drives the request and samples the DUT's returned data back into the transaction's response field (returned via item_done(rsp)) — the sampling step is essential and easily forgotten.
• Isolating the protocol in the conversion keeps the transaction, sequence, and scoreboard protocol-agnostic — so a different protocol means a different conversion and nothing else changes, which is the reuse payoff.
• The durable rule of thumb: map each field to its signal in the protocol's order, expand the beats exactly, keep the protocol entirely inside the conversion — and for reads, sample the returned data into the response field at the protocol's read latency, because a read conversion that only drives (forgetting the sample) loses its result, causing a scoreboard mismatch despite correct pin-level behavior.

Next — Interface Driving: the conversion maps fields to signals; the next chapter drills into driving those signals — the virtual interface, synchronous driving with clocking blocks, avoiding races, and the signal-level mechanics of putting values on the pins correctly.