Case Study — An AXI Agent

Industry Case Studies · Module 30 · Page 30.2

The Engineering Problem

The APB agent taught the pattern — item, driver, monitor, active/passive — on the simplest protocol: one transfer at a time, one address-then-data handshake. AXI is the same pattern scaled to the protocol that carries the high-bandwidth traffic on a chip, and the scaling changes the agent's shape. AXI has five independent channels, supports bursts of many beats per transaction, allows many outstanding transactions in flight at once, and lets responses return out of order. A single sequential driver no longer fits: the agent must run channels concurrently and match responses to requests by ID.

The four facts that reshape the agent. (1) Five channels: write address (AW), write data (W), write response (B), read address (AR), read data (R) — each with its own VALID/READY handshake, operating independently. (2) Bursts: one transaction is AxLEN+1 beats; the final write-data beat is flagged with WLAST. (3) Concurrency: because the channels are independent, the driver runs them as concurrent processes, not a sequence. (4) The handshake rule: a source asserts VALID without waiting for the destination's READY — breaking this rule deadlocks the bus, the single most important thing to get right.

How do you build a UVM agent for AXI — the five independent channels, a burst-aware transaction, a driver that runs the write address, data, and response channels concurrently, and the VALID/READY rule — so the agent handles outstanding, out-of-order bursts the way a single-channel APB agent never has to?

Motivation — why AXI is the real step up

AXI is where a verification engineer's agent-building skill is actually tested, because the protocol's concurrency breaks the simple sequential driver:

• Concurrency is the new idea. APB is sequential — one transfer, fully complete, then the next. AXI's five channels run at once: write data can flow while the next write address is issued, and reads proceed independently of writes. The driver has to model this concurrency, which is a genuinely different design from APB's single loop.
• Bursts make the transaction richer. One AXI transaction is many beats, so the item carries a data array and a length, and the driver loops beats with WLAST — a step up from APB's single data word.
• Outstanding and out-of-order are why IDs exist. AXI lets multiple transactions be in flight and lets responses come back in a different order, identified by ID — the feature that gives AXI its bandwidth and the reason the scoreboard must match by ID, not by order.
• The handshake rule is a real, famous bug. The rule that VALID must not wait for READY is exactly the kind of protocol subtlety that, broken, causes a silent deadlock — and it is one of the most common AXI bring-up bugs, so building it in correctly is the lesson.

The motivation, in one line: AXI scales the APB agent pattern with concurrency, bursts, and outstanding out-of-order transactions, so building it is where you learn to model independent concurrent channels, ID-matched responses, and the VALID/READY discipline that keeps the bus from deadlocking.

Mental Model

Hold the AXI agent as a busy seaport with five independent docks, not APB's single service counter:

APB is a single service counter: one customer at a time, hand over the form, wait for it to be processed, take the receipt, next customer. AXI is a container seaport, and the difference is everything. The port has five separate docks operating independently and simultaneously: an inbound-manifest dock where ships declare what they are delivering (write address), a cargo-unloading dock where the containers actually come off (write data), an outbound-receipt dock where delivery confirmations are issued (write response), and two more for the pickup side (read address and read data). These docks do not take turns — while one ship's cargo is being unloaded, the next ship is already filing its manifest, and confirmations for earlier ships go out on their own dock meanwhile. Every ship carries an ID painted on its hull, which is what makes the chaos manageable: the port can accept a dozen manifests before any cargo is unloaded (outstanding), and it can issue confirmations in whatever order the unloading finishes, not the order the manifests arrived (out of order), because the ID on each confirmation says which ship it belongs to. And there is one ironclad rule at every dock that keeps the port from gridlocking: a ship raises its "ready to transfer" flag whenever it has cargo to move, and it does not first wait to see the dock's "ready to receive" flag — both sides raise their flags independently, and the transfer happens the moment both are up. If a ship refused to raise its flag until it saw the dock's flag, and the dock refused to raise its flag until it saw the ship's, both would wait forever, staring at each other, and the whole port would freeze. APB is a single service counter — one at a time, sequential. AXI is a container seaport with five independent docks operating simultaneously: a manifest dock (write address), a cargo-unloading dock (write data), a confirmation dock (write response), and two for pickup (read address, read data). The docks do not take turns. Every ship carries an ID, which is what lets the port accept many manifests before unloading (outstanding) and issue confirmations out of order (matched by ID). And one ironclad rule prevents gridlock: a ship raises its ready flag without first waiting to see the dock's flag — both sides raise independently, and transfer happens when both are up. If each waited to see the other's flag first, both would wait forever and the port would freeze.

So building the AXI agent is running the seaport: the transaction is a ship with an ID and a hold full of containers (the burst beats); the driver works the five docks concurrently (concurrent processes per channel), flagging the last container with WLAST; the handshake at every dock follows the rule — assert VALID independent of READY — and the IDs let responses come back out of order, matched to their requests. The deadlock you must never write is the two-sided wait where VALID is conditioned on READY.

The Five Channels in One Figure

AXI's five channels split into a write group and a read group. Each is an independent VALID/READY handshake; the groups operate concurrently.

The figure is the protocol's structure. Writes use three channels: AW carries the address and burst parameters once per transaction; W carries the data, one transfer per beat, with WLAST on the final beat; B returns a single response per transaction, tagged with BID. Reads use two: AR mirrors AW, and R returns the read data, one beat at a time with a per-beat response and RLAST on the last. The defining property is independence: the five handshakes are separate, so the channels operate concurrently — and that concurrency is exactly what the driver must model. The IDs threaded through every channel are what make outstanding, out-of-order traffic possible: a B response carries the BID that says which AW it answers, so responses need not come back in request order.

The Independent-Handshake Rule

Every AXI channel uses the same VALID/READY handshake, and it has one rule that, broken, deadlocks the bus: a source asserts VALID without waiting for READY.

The rule is precise and asymmetric. A source (the master on AW, W, AR; the slave on B, R) asserts VALID the moment it has a payload to send, and the payload plus VALID must stay stable until the transfer completes. A destination asserts READY when it can accept. The transfer happens on the cycle both are high. The forbidden pattern is making VALID depend on READY: the protocol explicitly forbids a source from waiting to observe READY before asserting VALID. The reason is the deadlock in the caption — if both sides wait to see the other's flag first, neither ever raises its own, and the channel hangs. (The reverse is allowed: a destination may wait for VALID before asserting READY.) This single rule is the difference between an AXI driver that works and one that hangs at bring-up — and it is the DebugLab below.

The Agent Hierarchy

The AXI agent has the same outer shape as APB — sequencer, driver, monitor under an agent, with a scoreboard at env level — but the driver internally runs concurrent per-channel processes rather than one loop.

The hierarchy is deliberately the same agent shape you learned for APB — the reusable-agent pattern does not change with the protocol. The monitor is unconditional, the sequencer and driver are built only when active, and the driver connects to the sequencer in connect_phase. What is new lives inside the components: the driver's run_phase forks concurrent channel processes instead of running a single sequential transfer, and the monitor watches all five channels at once, assembling each multi-beat burst and matching responses to requests by ID before it broadcasts a completed transaction. The lesson is that the architecture scales without changing while the channel handling grows richer.

The Transaction

The AXI transaction is burst-aware: it carries the ID, the address, the burst parameters, an array of data beats, and a per-beat response — far richer than APB's single word.

typedef enum bit [1:0] { FIXED = 2'b00, INCR = 2'b01, WRAP = 2'b10 } axi_burst_e;
 
class axi_seq_item extends uvm_sequence_item;
  rand bit [3:0]    id;
  rand bit [31:0]   addr;
  rand bit [7:0]    len;       // AxLEN: number of beats minus 1
  rand bit [2:0]    size;      // AxSIZE: bytes per beat = 2**size
  rand axi_burst_e  burst;     // FIXED / INCR / WRAP
  rand bit          write;     // 1 = write, 0 = read
  rand bit [31:0]   data[];    // one entry per beat (len+1 entries)
  bit [1:0]         resp[];    // response per beat (R) or one entry (B)
 
  constraint c_beats { data.size() == len + 1; }
  constraint c_size  { size <= 2; }            // up to 4 bytes/beat on a 32-bit bus
 
  `uvm_object_utils_begin(axi_seq_item)
    `uvm_field_int(id,    UVM_ALL_ON)
    `uvm_field_int(addr,  UVM_ALL_ON)
    `uvm_field_int(len,   UVM_ALL_ON)
    `uvm_field_int(write, UVM_ALL_ON)
    `uvm_field_array_int(data, UVM_ALL_ON)
  `uvm_object_utils_end
 
  function new(string name = "axi_seq_item");
    super.new(name);
  endfunction
endclass

The item models the whole burst as one transaction. len is AxLEN — beats minus one — and the c_beats constraint keeps the data array sized to match (len + 1 entries). size is the bytes-per-beat exponent, burst selects the address pattern (INCR is the common one), and id is the transaction identifier that lets this transaction be outstanding and its response come back out of order. The per-beat resp array holds the read responses (one per R beat) or the single write response (B). Registering data with `uvm_field_array_int gives the dynamic array automatic copy, compare, and print. One item, one burst — the driver expands it into multiple channel transfers.

The Write Path — running AW, W, and B concurrently

A write spans three channels. The driver drives the address on AW, streams the data beats on W (flagging WLAST), and collects the response on B — and because the channels are independent, it runs them as concurrent processes, each obeying the VALID/READY rule.

class axi_driver extends uvm_driver #(axi_seq_item);
  `uvm_component_utils(axi_driver)
  virtual axi_if vif;
  // ... new(), build_phase get vif (guarded with `uvm_fatal) ...
 
  task run_phase(uvm_phase phase);
    reset_outputs();
    forever begin
      axi_seq_item tr;
      seq_item_port.get_next_item(tr);
      if (tr.write) drive_write(tr);
      else          drive_read(tr);
      seq_item_port.item_done();
    end
  endtask
 
  task drive_write(axi_seq_item tr);
    // The three write channels are independent → run them concurrently.
    fork
      drive_aw(tr);          // write address
      drive_w(tr);           // write data beats
      collect_b(tr);         // write response
    join                     // transaction done when all three complete
  endtask
 
  task drive_aw(axi_seq_item tr);
    @(posedge vif.clk);
    vif.awid    <= tr.id;
    vif.awaddr  <= tr.addr;
    vif.awlen   <= tr.len;
    vif.awsize  <= tr.size;
    vif.awburst <= tr.burst;
    vif.awvalid <= 1'b1;                          // assert VALID — do NOT wait for AWREADY
    do @(posedge vif.clk); while (!vif.awready);  // transfer when both high
    vif.awvalid <= 1'b0;
  endtask
 
  task drive_w(axi_seq_item tr);
    foreach (tr.data[i]) begin
      @(posedge vif.clk);
      vif.wdata  <= tr.data[i];
      vif.wlast  <= (i == tr.len);                // WLAST on the final beat
      vif.wvalid <= 1'b1;                          // assert VALID — do NOT wait for WREADY
      do @(posedge vif.clk); while (!vif.wready);  // beat transfers when both high
    end
    vif.wvalid <= 1'b0; vif.wlast <= 1'b0;
  endtask
 
  task collect_b(axi_seq_item tr);
    vif.bready <= 1'b1;                            // ready to accept the response
    do @(posedge vif.clk); while (!vif.bvalid);   // wait for the slave's B
    tr.resp = new[1]; tr.resp[0] = vif.bresp;      // BID == tr.id identifies it
    vif.bready <= 1'b0;
  endtask
endclass

drive_write is the heart of the difference from APB: a fork … join runs the AW, W, and B channels concurrently, because they are independent and may overlap — the slave can accept write data before, during, or after it accepts the address, and the response comes whenever the slave is done. Each channel task is a VALID/READY handshake that asserts VALID first and then waits for READY (the do … while polls READY after VALID is up) — never the reverse, which is the deadlock. drive_w loops the data array, asserting WLAST on the final beat (i == tr.len) so the slave knows the burst is complete. collect_b raises BREADY and waits for BVALID, capturing the response whose BID matches this transaction's id. Phase placement is unchanged: vif in build_phase, all driving in run_phase.

The Read Path and the Monitor

A read uses AR and R: drive the address, then collect len + 1 data beats until RLAST. The monitor watches every channel concurrently and reconstructs whole bursts, matching by ID.

  task drive_read(axi_seq_item tr);
    fork
      drive_ar(tr);                                // read address (like AW)
      collect_r(tr);                               // read data beats
    join
  endtask
 
  task collect_r(axi_seq_item tr);
    int i = 0;
    tr.data = new[tr.len + 1]; tr.resp = new[tr.len + 1];
    vif.rready <= 1'b1;
    forever begin
      do @(posedge vif.clk); while (!vif.rvalid);  // each beat: wait for RVALID
      tr.data[i] = vif.rdata;
      tr.resp[i] = vif.rresp;                       // per-beat response
      if (vif.rlast) break;                         // RLAST ends the burst
      i++;
    end
    vif.rready <= 1'b0;
  endtask

class axi_monitor extends uvm_monitor;
  `uvm_component_utils(axi_monitor)
  virtual axi_if vif;
  uvm_analysis_port #(axi_seq_item) ap;
  // ... new() creates ap; build_phase gets vif ...
 
  task run_phase(uvm_phase phase);
    fork
      monitor_writes();   // observe AW + W (+ B), assemble each write burst, ap.write(tr)
      monitor_reads();    // observe AR + R, assemble each read burst, ap.write(tr)
    join                  // all channels watched concurrently
  endtask
endclass

The read path mirrors the write but with two channels: drive_ar issues the address and collect_r loops beats, sizing the data and response arrays to the burst and ending on RLAST. The monitor's run_phase forks concurrent observers — one assembling write bursts from AW/W/B, one assembling read bursts from AR/R — because, like the driver, it must watch independent channels at once. Each observer reconstructs a whole multi-beat transaction from the pins and broadcasts it on the analysis port, matched to its request by ID, so the scoreboard receives complete, identified transactions to check.

Outstanding and Out-of-Order, by ID

Because every channel carries an ID, a master can issue several addresses before any response returns (outstanding), and the slave can return responses in a different order than the requests (out of order) — each response routed to its request by matching BID/RID to the original AWID/ARID. A production driver therefore does not block one transaction's fork … join before starting the next; it launches transactions with fork … join_none and tracks them by ID, and the scoreboard keys its expected-versus-observed matching on ID rather than on arrival order. The agent shown here drives one transaction at a time for clarity, but the transaction's id field and the by-ID monitor reconstruction are exactly what a multi-outstanding extension builds on — the structure is already ID-aware.

Waveform Perspective — an AXI write burst

A two-beat write burst shows the channels operating independently: the address handshakes once on AW, the two data beats handshake on W with WLAST on the second, and the response returns on B — each on its own VALID/READY pair.

The waveform makes the channel independence concrete. The AW handshake completes once, in cycle 1, carrying the burst's address and len. The W channel then transfers two beats — D0 in cycle 2, D1 in cycle 3 with WLAST high to mark the end of the burst — each beat its own WVALID/WREADY handshake. The B response returns in cycle 4 with its BID matching the AWID. Each VALID rises from its source independently of READY, and each transfer lands on the cycle both flags are high. This is the seaport running: the manifest filed once, the containers unloaded one per cycle with the last one flagged, the confirmation issued when the slave is done — three docks, three independent handshakes, one transaction.

DebugLab — the handshake that deadlocked the bus

buggy driver:  do @(posedge clk); while (!vif.awready);   // wait for READY first ✗
               vif.awvalid <= 1'b1;                        // assert VALID only after
slave:         asserts AWREADY only after it sees AWVALID
result:        driver waits for AWREADY, slave waits for AWVALID → neither moves → deadlock
fix:           vif.awvalid <= 1'b1;                        // assert VALID first ✓
               do @(posedge clk); while (!vif.awready);    // THEN wait for READY

Common Mistakes

• Conditioning VALID on READY. A source must assert VALID without waiting for READY; waiting first deadlocks against a slave that waits for VALID — the DebugLab hang.
• Driving the channels sequentially instead of concurrently. AW, W, and B are independent and may overlap; a driver that fully finishes AW before starting W mismodels the protocol and serializes what should be concurrent. Use fork … join.
• Forgetting WLAST (or RLAST). The final data beat must be flagged; without WLAST the slave waits for more beats and the burst never completes.
• Sizing the burst wrong. The data array must hold AxLEN + 1 beats; an off-by-one against len drives too few or too many beats. Constrain data.size() == len + 1.
• Matching responses by order instead of ID. Responses can return out of order; the scoreboard must match BID/RID to the request's ID, not assume FIFO order.
• Changing payload or dropping VALID mid-handshake. Once VALID is asserted, the payload and VALID must stay stable until the transfer completes.

Senior Design Review Notes

Interview Insights

Exercises

1. Size the burst. For an INCR write with len = 3 and size = 2 on a 32-bit bus, state how many W beats are driven, which one asserts WLAST, and how many bytes the transaction moves.
2. Spot the deadlock. Given a driver that polls AWREADY before asserting AWVALID, explain why it hangs against a compliant slave and give the one-line reorder that fixes it.
3. Make it concurrent. Rewrite a sequential drive_aw(); drive_w(); collect_b(); as the correct concurrent form, and explain what overlap it now allows that the sequential version forbade.
4. Match by ID. Describe how a scoreboard would handle two outstanding reads whose responses return out of order, and what would break if it matched by arrival order instead.
5. Extend to outstanding. Outline what changes in the driver to allow two writes in flight at once, and why the transaction's id field is the prerequisite.

Summary

• An AXI agent is the APB pattern scaled by concurrency: five independent channels (AW, W, B for writes; AR, R for reads), each an independent VALID/READY handshake, operating at once.
• The transaction is burst-aware — id, address, length (AxLEN, beats − 1), size, burst type, a data array, and per-beat responses — and the driver runs the channels concurrently with fork … join, asserting WLAST/RLAST on the final beat.
• The handshake rule is non-negotiable: a source asserts VALID independently of READY; conditioning VALID on READY deadlocks the channel against a compliant slave — the both-signals-low-forever hang.
• IDs enable outstanding and out-of-order traffic: many transactions in flight, responses returned in any order and matched back by BID/RID, so the monitor and scoreboard must key on ID, not arrival order.
• The agent's outer shape is unchanged from APB — item, sequencer, driver, monitor, active/passive, factory-built, config-driven — which is the lesson: the reusable-agent architecture is protocol-independent; only the channel handling grows.
• The durable rule of thumb: build the AXI agent as the same agent pattern with concurrent per-channel processes, a burst transaction, and ID-based matching — drive every channel by asserting VALID before polling READY, flag the last beat with WLAST/RLAST, and match responses by ID — because AXI's bandwidth comes from concurrent, outstanding, out-of-order channels, and the one rule that keeps them from deadlocking is that VALID never waits for READY.

Next — UART Agent: APB was single-channel and synchronous; AXI added concurrent channels. The next case study takes on a different axis — a serial, asynchronous interface — where the agent must recover timing from a start bit, sample in the middle of each bit at a configured baud rate, and handle framing and parity, showing how the same agent pattern adapts to a protocol with no shared clock at all.