AMBA AXI · Module 5

Read Data Interleaving

Read data interleaving by ID in AXI3 and why AXI4 removed it — and the crucial difference between beat-level interleaving (gone) and out-of-order completion (still allowed).

When a manager has several reads outstanding, their data shares one R channel — and there are two very different ways it can come back. Read data interleaving means beats from different reads are intermixed on R (RID0, RID1, RID0, RID1…), each sorted by its RID. AXI3 allowed it; AXI4 removed it. But the removal is narrower than it sounds, and the distinction is the whole point of this chapter: AXI4 still permits reads to complete out of order (a whole later read returning before an earlier one) — it just forbids interleaving their beats. This is the read-side counterpart of the write WID story (4.4), and confusing "interleaving" with "out-of-order completion" is the classic mistake.

A manager can have multiple reads outstanding (different ARIDs, Chapter 5.2). Their data all returns on the single R channel, and RID tags every beat with the read it belongs to. The question is how the subordinate is allowed to schedule those beats onto the one channel:

Contiguous (AXI4): return all of one read's beats (through its RLAST), then all of the next read's. Beats are never intermixed.
Interleaved (AXI3): return beats from different reads intermixed — RID0, RID1, RID0, RID1 — relying on RID to let the manager demux them.

Both rely on RID to identify beats; the difference is whether the subordinate may switch between reads mid-burst. AXI3 said yes (up to a depth); AXI4 says no.

2. What Read Interleaving Was (AXI3)

In AXI3, a subordinate serving several reads could return whatever data was ready first, beat by beat, even if that meant alternating between transactions. If read ID0 had its first beat ready and ID1's was still being fetched, the subordinate could send ID0's beat, then ID1's when it arrived, then ID0's next — intermixing them on R. The manager used RID on each beat to route it to the correct per-transaction buffer.

Figure 1 — AXI3 read-data interleaving. The manager has two reads outstanding (ID0 and ID1); the subordinate returns their beats intermixed on the single R channel — D0(ID0), E0(ID1), D1(ID0,RLAST), E1(ID1,RLAST) — and the manager demuxes by RID into the right read. AXI4 forbids this: it would return D0,D1 (all of ID0) then E0,E1 (all of ID1).

The motivation was utilization: a subordinate (or interconnect merging several slaves) needn't sit idle waiting for one read's slow beat when another read's beat is ready — it could fill the channel with whatever data is available. The cost was paid by the manager: to reassemble interleaved beats it needed a separate buffer per outstanding RID, and to track interleaving depth.

3. Read Interleaving on a Waveform

On R, interleaving shows up as RID changing between beats within the same window — the giveaway that two transactions are sharing the channel beat-by-beat.

read-interleave — RID alternates per beat (AXI3 only)

7 cycles

Figure 2 — AXI3 read interleaving on the R channel. Across cycles 1–4, RID alternates ID0, ID1, ID0, ID1 — beats from two reads intermixed. Each read's RLAST lands on its own last beat (ID0 at cycle 3, ID1 at cycle 4). On AXI4 this is illegal: RID would stay ID0 until ID0's RLAST, then switch to ID1. RID changing mid-window before a RLAST is the interleaving signature.

4. Interleaving ≠ Out-of-Order Completion

This is the distinction that matters most, and the one people get wrong. AXI4 removed interleaving (beat-level intermixing) but kept out-of-order completion (whole-transaction reordering):

Out-of-order completion (allowed in AXI4): reads with different ARIDs may complete in any order — a later-issued read can return entirely (all its beats, through RLAST) before an earlier one. This is the latency-hiding behavior from Chapters 2.4/5.4, and AXI4 keeps it.
Interleaving (removed in AXI4): the beats of two reads intermixed on R within the same window. AXI4 requires each read's beats to be contiguous — all of one read (through RLAST) before the next begins.

So in AXI4 you can still get reads back in a different order than you asked — but each read arrives as one unbroken run of beats. The subordinate may choose which read to return next, but once it starts a read's data it must finish it before switching.

Figure 3 — the key distinction. Out-of-order completion (kept in AXI4): whole reads return in any order, but each is contiguous — e.g., all of ID1 then all of ID0. Interleaving (removed in AXI4): beats of different reads intermixed within a window — ID0, ID1, ID0, ID1. AXI4 allows reordering reads; it forbids intermixing their beats.

5. Why AXI4 Removed It

The trade was the same as the write-side WID removal (4.4): interleaving's benefit was marginal, its cost to managers was real. To reassemble interleaved read data, every manager needed a buffer per outstanding RID and logic to track interleaving depth — complexity paid on every master, for a utilization gain that mattered only in narrow cases. AXI4 made read data contiguous per transaction, so a manager handling the R channel deals with one active read at a time (it still demuxes by RID across completions, but never mid-burst). Simpler managers, negligible performance loss.

Figure 4 — why AXI4 removed read interleaving (mirroring the WID removal). AXI3 interleaving forced every manager to keep a reassembly buffer per outstanding RID and track interleave depth. AXI4's contiguous-per-read rule means one active read at a time on R — far simpler managers — while out-of-order completion still provides the reordering that matters.

When bridging AXI3 → AXI4, a converter must therefore de-interleave read data (buffer the AXI3 interleaved beats and emit each read's beats contiguously) — the read-side analogue of de-interleaving write data, and another behaviour a generation bridge must reconcile.

6. Single-Read Data Is Always In Order

One invariant holds across all AXI versions and is worth stating plainly: the beats of a single read (same ARID) always return in order. Interleaving (AXI3) only ever intermixed beats of different ARIDs; it never reordered the beats within one read. So a manager can always assume beat 0, then beat 1, … for a given RID, ending at that read's RLAST. Out-of-order and interleaving are about relationships between transactions; a single transaction's data is sequential, always.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — demux R beats by RID. Within an RID, beats are always in order.
read_buf[rid].push(rdata);             // append to this read's buffer (in order)
if (rlast) complete_read(rid);
// AXI3: rid may change between consecutive beats (interleaving) → need a buffer per RID.
// AXI4: rid is stable until that read's RLAST (contiguous) → one active read at a time,
//       though different reads may still COMPLETE out of order.

7. Common Misconceptions

Myths to unlearn

"AXI4 removed out-of-order reads." No — it removed interleaving (beat intermixing). Out-of-order completion of whole reads (different IDs) is still allowed and is how latency is hidden.
"Interleaving and out-of-order completion are the same." Different: out-of-order completion reorders whole, contiguous reads; interleaving intermixes beats of different reads within a window. AXI4 keeps the first, drops the second.
"A single read's beats can be interleaved/reordered." Never — beats of one ARID always return in order, in every AXI version. Interleaving only ever applied across different IDs.
"Read interleaving needed a special signal like write WID." No — read data already carries RID on every beat, so interleaving was possible without adding anything; that's why AXI3 allowed it (and AXI4 still uses RID for out-of-order completion).
"AXI3 and AXI4 read data look the same on a capture." AXI3 can show RID changing between beats before a RLAST (interleaving); AXI4 keeps RID stable until each read's RLAST. That signature distinguishes them.

8. Debugging Insight

🔍 Debugging insight — RID changing mid-burst is the interleaving tell

The signature to look for on R is RID changing between consecutive beats before a RLAST:

On an AXI4 bus, that's a violation. AXI4 requires contiguous read data — RID must stay constant from a read's first beat to its RLAST. If you see RID flip mid-burst on AXI4, a subordinate or (more likely) an un-de-interleaved AXI3 bridge is interleaving illegally — and a manager that assumed contiguous data will mis-assemble beats.
On an AXI3 bus, it's legal — but then verify the manager demuxes by RID correctly into per-transaction buffers, and that each read still ends with its own RLAST. A manager that assumed contiguous (AXI4-style) data will corrupt interleaved reads.
Distinguish from out-of-order completion. If whole reads return contiguously but in a different order than issued (all of ID1's beats with its RLAST, then all of ID0's), that's legal in both versions — not a bug. Only beat-level RID switching before a RLAST is interleaving.
Within one read, beats must be ordered. If a single RID's beats arrive out of order, that's a bug in any version.

So: RID stable-until-RLAST is AXI4-correct; RID switching mid-burst is AXI3 interleaving (a bug on AXI4); whole-read reordering is fine everywhere.

9. Verification Insight

✅ Verification insight — assert no-interleaving on AXI4, exercise it on AXI3

The verification posture depends on the version, and the monitor must distinguish the two reordering kinds. On AXI4, bind an assertion that read data is contiguous per RID: once a read's first beat appears, RID must not change until that read's RLAST — this catches illegal interleaving (including from a bridge). Separately, allow and cover out-of-order completion: issue multiple reads with distinct ARIDs and verify the monitor correctly handles whole reads returning in a different order than issued. The monitor reassembles per RID (5.2) and checks each read's beat count/RLAST regardless of completion order.

On AXI3 (or an AXI3 leg of a bridge), you must exercise interleaving: the responder agent should interleave beats of different-ID reads up to the configured depth, and the manager/monitor must demux correctly — and for a bridge, assert the AXI4 side emerges de-interleaved and contiguous. Coverage wants: out-of-order completions, (AXI3) interleaved returns at varying depths, and the single-read-in-order invariant. The headline AXI4 check is the contiguity assertion; the headline bridge check is correct de-interleaving. Mechanics in Module 16.

10. Interview Questions

11. Summary

When multiple reads are outstanding, their beats share one R channel, and AXI3 allowed interleaving — intermixing beats of different-ID reads (RID0, RID1, RID0…), demuxed by the RID already present on every beat. AXI4 removed read interleaving, requiring each read's data to be contiguous (all of one read through its RLAST before the next). The removal mirrors the write-side WID/interleaving removal: interleaving's benefit was marginal and it forced every manager to keep a per-RID reassembly buffer, so AXI4 traded it for simpler managers.

The distinction to keep crisp: AXI4 dropped beat-level interleaving but kept out-of-order completion — whole reads (different IDs) may still return in any order, each contiguous — which is what hides latency. And in every version, a single read's beats are always in order. The interleaving signature on a capture is RID changing mid-burst before a RLAST (legal on AXI3, a violation on AXI4); an AXI3→AXI4 bridge must de-interleave. Next, Module 5 closes with annotated end-to-end read waveforms.

12. What Comes Next

The read path's mechanics are complete; next, see them assembled:

5.6 — Read Transaction Waveforms (coming next) — annotated end-to-end read waveforms: single, burst, and multi-ID.

Previous: 5.4 — Read Latency. For the broader protocol catalog, see the AMBA family overview doc.

1. Sharing the R Channel Among Reads