AMBA AXI · Module 5

The Read Address (AR) Channel

Every AR signal and how a read is launched — ARADDR, the burst shape (ARLEN/ARSIZE/ARBURST), ARID and RID pairing, and the AR handshake. AR is AW's read-side twin.

Module 5 walks the read path, and it opens where a read begins — the AR (read address) channel. The good news: AR is the read-side twin of AW. It carries the same kind of payload (address, burst shape, ID, attributes) and launches a read with one handshake exactly as AW launches a write. So if you know AW (Chapter 4.1), you already know most of AR. This chapter details the AR signals, highlights the one structural difference (a read's answer returns as data with an ID on R, not as a separate response), and watches the AR handshake. Burst-address math is Module 7; here it's the AR channel and how it launches a read.

1. AR Launches the Read — AW's Twin

AR is the manager saying "I want to read — here's where and what shape." Like AW, it is purely a request: it names the target and describes the transfer, and one AR handshake commits the manager to one read transaction. And like AW, AR carries no data — the data comes back on the R channel.

The symmetry is near-total. Every AW signal has an AR counterpart with the same meaning:

ARADDR ↔ AWADDR, ARLEN ↔ AWLEN, ARSIZE ↔ AWSIZE, ARBURST ↔ AWBURST
ARID ↔ AWID, and the attributes ARLOCK/ARCACHE/ARPROT/ARQOS/ARREGION/ARUSER ↔ the AW* set
ARVALID/ARREADY ↔ AWVALID/AWREADY

So everything you learned about AW's geometry and handshake applies to AR unchanged. The differences are on the return side: a write's answer is a one-beat B response, while a read's answer is the data itself, returned on R with a matching RID — there is no separate read "response channel" (4.3). We focus here on what's the same (because it's most of it) and flag what's different.

2. What AR Carries

AR's signals group into the same four roles as AW, moved together by the ARVALID/ARREADY handshake.

Figure 1 — the AR channel's signals by role, mirroring AW. The address (ARADDR) says where to read; the shape (ARLEN/ARSIZE/ARBURST) says how many beats, how wide, and what address pattern; the identity (ARID) tags the read for outstanding/ordering and matches the RID on returned data; the attributes carry access hints. ARVALID/ARREADY transfer the bundle.

In code, AR is a read-request descriptor — identical in shape to AW's:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — the AR channel as a read-request descriptor (twin of aw_payload_t).
typedef struct packed {
  logic [ADDR_W-1:0] araddr;   // start address — where the read begins
  logic [7:0]        arlen;    // beats - 1  (AXI4: 0..255 → 1..256 beats)
  logic [2:0]        arsize;   // bytes per beat = 2**arsize
  logic [1:0]        arburst;  // FIXED / INCR / WRAP — how the address steps
  logic [ID_W-1:0]   arid;     // read id — matches RID on the returned data
  // + arlock, arcache, arprot, arqos, arregion, aruser (attributes)
} ar_payload_t;                // moved by one ARVALID/ARREADY handshake

3. The Address and the Shape

Exactly as on the write side, four signals describe what read is launched:

ARADDR — the start address (of the first beat for a burst).
ARLEN — beats − 1 (so ARLEN=0 is one beat, ARLEN=7 is eight; up to 256-beat INCR in AXI4).
ARSIZE — bytes per beat (2^ARSIZE), not exceeding the data-bus width.
ARBURST — FIXED / INCR / WRAP, how the address steps between beats.

These declare the geometry of the read, and they obligate the return: the subordinate must return exactly ARLEN+1 R beats of ARSIZE width, stepping per ARBURST, ending in RLAST. The AR shape is the contract the R channel fulfills — the read-side mirror of "AW declares the shape W delivers."

Figure 2 — AR and AW are twins; only the return side differs. Both carry address + shape + ID and launch a transaction with one handshake. A write's answer is a separate single B response; a read's answer is the data itself on R, tagged with RID. So AR has no 'B' — the R data is both the payload and the acknowledgement.

4. ARID — Read Ordering and RID Pairing

ARID is the read transaction's identifier, the twin of AWID — and the hook for outstanding, concurrent reads. Reads with the same ARID must return in order; reads with different ARIDs may return out of order. Each returned R beat carries an RID matching the ARID of the read it belongs to, so a manager with several reads in flight can sort the returning data back to the right transaction.

There's a read-specific nuance worth previewing: because read data is tagged per beat with RID, AXI3 even allowed read-data interleaving — beats from different-ID reads mixed on R — which AXI4 removed (the read analogue of the write-side WID story). The depth of that (read interleaving, ordering across IDs) is Modules 5.5/8; for launching a read, the point is that ARID scopes ordering and pairs with RID.

5. The AR Handshake

AR uses the universal handshake: the manager drives ARVALID with the AR bundle; the subordinate raises ARREADY; on the edge where both are high, the address is accepted and the read is launched.

AR handshake — launching an 8-beat read

7 cycles

Figure 3 — the AR handshake. The manager drives ARVALID with the address and burst description (ARADDR=0x40, an 8-beat INCR burst of 4-byte beats); ARREADY is low for a cycle, so the manager holds the AR payload stable; the address is accepted at the edge where ARVALID and ARREADY are both high, launching the read. One handshake launches the whole read.

All the handshake rules apply unchanged: ARVALID must not wait for ARREADY (cardinal rule), the AR payload stays stable while waiting (stability), and ARREADY may be asserted before or after ARVALID. Once the AR handshake completes, the manager's address phase is done; the data returns on R.

6. AR in the Read Lifecycle

AR is the opener of the two-channel read (Chapter 2.2): the AR handshake launches the transaction, and the R channel then returns the beats whose count and shape AR declared.

Figure 4 — AR as the opener. The AR handshake launches the read and declares its shape; the R channel then returns exactly ARLEN+1 beats of ARSIZE width stepping per ARBURST, each tagged RID (matching ARID), with RLAST on the last and a per-beat RRESP. AR commits the geometry; R carries it out — there is no third channel.

7. Common Misconceptions

Myths to unlearn

"AR carries the read data." No — AR carries only the request (address, shape, ID, attributes). The data returns on the R channel. AR launches; R answers.
"ARLEN is the number of beats." It's beats minus one — ARLEN=0 is one beat, ARLEN=7 is eight. Same off-by-one trap as AWLEN. The R channel must return exactly ARLEN+1 beats.
"A read needs a separate response channel like B." It doesn't — the returning R data is the acknowledgement, with RRESP per beat and RID for pairing. That's the structural read-vs-write difference.
"AR and AW are different protocols." They're twins — same payload roles, same handshake. If you know AW, you know AR; only the return side (R data vs B response) differs.
"ARID is decorative." It scopes read ordering (same-ID in order, different-ID may reorder) and pairs returned data via RID. It's central to outstanding, concurrent reads.

8. Debugging Insight

🔍 Debugging insight — the AR handshake is the read's contract

Just like AW for writes, the AR handshake is your ground truth for what the master intended to read — capture it first:

Find the AR handshake (ARVALID && ARREADY) and read the bundle: ARADDR (where), ARLEN (so expect ARLEN+1 R beats), ARSIZE (beat width), ARBURST (address pattern), ARID (so expect RID to match).
Check the R channel against it. Did exactly ARLEN+1 R beats return, ending in RLAST? Did each beat's RID match the ARID? Fewer/more beats, or mismatched RID, is a read-path bug (length mismatch or response mis-routing).
Sanity-check the shape. ARSIZE larger than the bus width, or a WRAP burst with an illegal length, is a malformed AR — the read is broken before any data returns.
No data after a clean AR? The AR was accepted but R never came — the read is stuck in the subordinate, or the address routed nowhere (check RRESP for DECERR when any R beat appears).

The AR handshake declares the contract for the whole read; most read bugs are the R channel disagreeing with what AR declared — so anchor on AR.

9. Verification Insight

✅ Verification insight — reuse the write agent's AR/AW symmetry

Because AR mirrors AW, a verification environment reuses the same machinery: the driver builds a random legal AR payload (address/len/size/burst/id within constraints) and the monitor captures the AR handshake to anchor the expected read — then checks the R channel against it (beat count = ARLEN+1, RLAST on the last, each RID = ARID, data matches the reference). The legality checks are the AW ones reused: ARSIZE ≤ bus width, WRAP length ∈ 16 and aligned, no 4KB-boundary-crossing burst (Module 7). Coverage wants the full cross of burst types × lengths × sizes × IDs, including single-beat (ARLEN=0) and max-length, plus multiple outstanding reads with distinct ARIDs to exercise out-of-order return and (on AXI3) interleaving.

The AR-specific additions over AW are about the return: cover reads that come back in order and out of order across IDs, and assert RID always pairs to an outstanding ARID. Protocol assertions bind to AR exactly as to AW (stability, cardinal rule, no malformed address). Mechanics in Module 16.

10. Interview Questions

11. Summary

The AR channel launches a read, and it is the read-side twin of AW: one ARVALID/ARREADY handshake commits the manager to one read and carries everything about it except the data — ARADDR (start), the shape (ARLEN beats−1, ARSIZE bytes/beat, ARBURST stepping), ARID (ordering + RID pairing), and the attribute set. Every AW signal has an AR counterpart with the same meaning, so knowing AW gives you AR for free. The one structural difference is the return: a read has no separate response channel — its answer is the data on R, tagged with RID (with RRESP per beat), versus a write's single B response.

Because AR fully declares the read's geometry, it's the anchor for debugging and verification: capture the AR handshake and you know to expect exactly ARLEN+1 R beats of ARSIZE width, each RID = ARID, ending in RLAST — and most read bugs are the R channel disagreeing with what AR declared. The handshake rules from Module 3 apply unchanged. Next, the data AR's shape described actually returns: the R channel, with RDATA, RRESP, RID, and RLAST.

12. What Comes Next

AR launched the read; now the data returns:

5.2 — The Read Data (R) Channel (coming next) — RDATA, RVALID/RREADY, RID, and how the data is delivered.
5.3 — RLAST & RRESP (coming soon) — per-beat RRESP and how RLAST closes a read burst.

Previous: 4.6 — Write Transaction Waveforms. For the broader protocol catalog, see the AMBA family overview doc.