AMBA AXI · Module 9

Read/Write Independence

Why AXI's read and write channels are fully decoupled — separate wires and handshakes operating concurrently (full-duplex) — what that independence enables for throughput, and the RAW/WAR/WAW hazards it leaves the master to manage.

Chapter 9.1 established that AXI never orders a read against a write. This chapter explains why — the read and write paths are physically and logically separate — and what that independence buys and costs. Reads use AR/R; writes use AW/W/B; the two sets of channels have their own handshakes and run concurrently and independently, like two one-way streets rather than a shared road. That decoupling is a major source of AXI's throughput (full-duplex read and write at once), but it hands the master the entire job of managing read/write hazards (RAW, WAR, WAW) where accesses actually depend on each other. This chapter covers both sides.

1. Two Separate Channel Sets

AXI's five channels split cleanly into two independent groups:

Read: AR (read address) + R (read data/response).
Write: AW (write address) + W (write data) + B (write response).

These are distinct wires with distinct VALID/READY handshakes. Nothing in the protocol couples them: a read address can be accepted while write data flows; a write response can return while read data streams. They are two parallel subsystems sharing only the subordinate they ultimately address. This is the structural reason for the "no read/write ordering" rule — there is literally no shared channel or handshake to impose an order.

Figure 1 — the read and write channel sets are independent. Read uses AR/R; write uses AW/W/B; each has its own VALID/READY handshakes and runs concurrently. A read and a write proceed in parallel with no protocol coupling — which is exactly why the bus imposes no ordering between them.

2. Full-Duplex — What Independence Enables

Because reads and writes don't share wires or block each other, a manager can drive both directions at once — full-duplex:

Concurrent throughput — the read-data bus and write-data bus can both be busy in the same cycles, so a mixed read/write workload approaches the sum of both directions' bandwidth, not a shared total.
No cross-direction blocking — a stalled write (slow B, backed-up W) doesn't hold up reads, and a slow read doesn't hold up writes. Each direction flow-controls itself.
Independent outstanding pools — reads and writes have separate ID spaces and separate in-flight tracking, so depth in one doesn't consume the other.

This is a real architectural advantage over a shared read/write bus (like older single-channel protocols): a DMA can read a source and write a destination simultaneously, a CPU can fetch while storing, and the interconnect can keep both data buses saturated.

rw-independence — read and write data flowing concurrently

7 cycles

Figure 2 — rw-independence: the read and write data channels active in the same cycles (full-duplex). RVALID returns read data while WVALID drives write data concurrently — the two directions don't share wires or block each other, so a mixed workload uses both buses at once.

3. The Cost — Read/Write Hazards Are the Master's Job

Independence means the bus provides no coherency between a read and a write to the same location. Where accesses genuinely depend on each other, the master must manage three classic hazards:

RAW (read-after-write) — a read of a location just written. Without enforcement, the read may be serviced before the write lands and return old data. Fix: issue the write, wait for its B response, then issue the read.
WAR (write-after-read) — a write to a location currently being read. The write may clobber the data before the read captures it. Fix: issue the read, wait for its final R beat, then issue the write.
WAW (write-after-write) — two writes to the same location. They may land in either order, leaving an undefined final value. Fix: give them the same AWID (same-ID ordering) or serialize.

The unifying point: the master must insert a response-wait at any read↔write dependency (RAW/WAR) and use a shared ID or serialization for write↔write (WAW). The bus will not detect or resolve these — independence is total.

Figure 3 — the three read/write hazards and their fixes. RAW (read after write) → wait for B before the read. WAR (write after read) → wait for final R before the write. WAW (write after write) → same AWID or serialize. The bus enforces none of these; the master must, at every genuine same-location dependency.

4. The Trade-Off

The decoupling is a deliberate trade: full-duplex performance in exchange for master-managed hazards. It pays off because the overwhelming majority of read and write traffic is to different locations (independent), where the parallelism is pure gain and no hazard exists. Only the relatively rare genuine read↔write dependency needs a response-wait, so the cost is concentrated and small while the benefit (both buses busy, no cross-blocking) is pervasive.

The design discipline is the same as Chapter 9.1's: assume no read/write ordering, enjoy the concurrency everywhere, and pay the serialization cost only at real same-location dependencies. A master that over-serializes (waits between every read and write) throws away the full-duplex advantage; one that under-serializes (ignores a RAW/WAR/WAW) corrupts data.

Figure 4 — the trade-off. Read/write independence delivers full-duplex throughput and no cross-direction blocking (the pervasive benefit, since most accesses are independent), at the cost of master-managed RAW/WAR/WAW hazards (the concentrated cost, only at real same-location dependencies). Over-serializing wastes the benefit; under-serializing corrupts data.

5. Common Misconceptions

Myths to unlearn

"Reads and writes share a data bus." No — they're separate channels (AR/R vs AW/W/B) with independent handshakes, so both can be active at once (full-duplex).
"The bus keeps reads and writes to the same address coherent." It does not — read/write independence is total; same-location RAW/WAR/WAW hazards are the master's responsibility.
"A slow write will hold up my reads." It won't — each direction flow-controls independently. Cross-direction blocking doesn't happen at the protocol level.
"Sharing an ID makes a read and write coherent." No — separate ID spaces; only a response-wait orders a read against a write.
"I should serialize reads and writes to be safe." Over-serializing throws away the full-duplex benefit. Serialize only at genuine same-location dependencies; let independent accesses run concurrently.

6. Debugging Insight

🔍 Debugging insight — same-location read/write bugs and lost full-duplex throughput

Two failure modes bracket read/write independence — under- and over-using it:

A read returns old data after writing the same location (RAW)? No B-wait between the write and the read — the read raced ahead of the write landing. Insert the response-wait: write → B → read.
A write corrupts data a read should have captured (WAR)? No wait for the read's final R before the write — the write clobbered the location mid-read. Wait: read → final R → write.
A location's final value is nondeterministic after two writes (WAW)? The writes used different AWIDs — unordered. Give them the same AWID or serialize.
Throughput far below the sum of read+write bandwidth? The master is over-serializing — inserting waits between independent reads and writes that have no dependency, collapsing full-duplex into half-duplex. Remove the unnecessary serialization; let independent accesses overlap.

The triage: data-correctness bug at a shared location → a missing RAW/WAR/WAW fix (under-serialized); throughput bug with correct data → unnecessary cross-direction serialization (over-serialized). Independence must be used exactly where appropriate — not too little, not too much.

7. Verification Insight

✅ Verification insight — hazard correctness and full-duplex concurrency

Verify both the correctness the independence demands and the concurrency it enables. For hazards: generate read/write pairs to overlapping addresses and confirm the master enforces RAW (waits for B before the dependent read), WAR (waits for final R before the write), and WAW (same AWID or serialized) — driving the bus to complete them in the "wrong" order (legal under independence) to prove the master created the needed order rather than relying on the bus. A reference memory checks that the dependent access sees the correct value. For concurrency: drive simultaneous read and write streams and assert they proceed full-duplex (both data channels active, no cross-direction blocking) — and that a stalled write doesn't stall reads or vice versa.

Coverage should include independent read/write traffic (full-duplex, no hazard), each hazard type at overlapping addresses, and the adversarial completion orderings that expose a missing wait. The highest-value tests are the same-address RAW/WAR with the bus completing out of dependency order (catches under-serialization) and the mixed independent stream (confirms the design doesn't needlessly serialize, i.e., achieves full-duplex). This builds directly on the ordering matrix of 9.1 and feeds the exclusive-access and dependency chapters next.

8. Interview Questions

9. Summary

AXI's read and write paths are fully independent — separate channel sets (AR/R vs AW/W/B) with their own handshakes, running concurrently with no protocol coupling. That's the structural reason the bus never orders a read against a write, and it enables full-duplex operation: both data buses busy at once, no cross-direction blocking, separate outstanding pools — a pervasive throughput win since most traffic targets independent locations. The cost is that the bus offers no read/write coherency, so the master must manage same-location hazards itself: RAW (wait for B before the read), WAR (wait for final R before the write), and WAW (same AWID or serialize).

The discipline mirrors 9.1: assume no read/write ordering, run everything concurrently, and serialize only at genuine same-location dependencies — under-serializing corrupts data (the memmove-style overlap bug), over-serializing collapses full-duplex into half-duplex. A high-performance master makes hazard handling precise and local (conflict-detect outstanding overlaps) rather than blanket. Next: exclusive access — the one place AXI does provide a hardware mechanism for atomic read-modify-write, via the exclusive monitor and EXOKAY.

10. What Comes Next

You've got the read/write decoupling; next, the atomic mechanism layered on top of it:

9.3 — Exclusive Access (coming next) — the exclusive monitor, load-/store-exclusive semantics, and the EXOKAY response for atomic read-modify-write.

Previous: 9.1 — Read & Write Ordering. Related: Five Channels and Independent Channels for the channel structure this builds on. For the broader protocol catalog, see the AMBA family overview doc.