AMBA AXI · Module 2

The Write Path

Walk an AXI write end-to-end across the AW, W, and B channels — address, data with WSTRB and WLAST, and the single BRESP response that confirms the write landed.

The read path used two channels because the returning data was its own acknowledgement. A write has no returning data — so it needs three channels: AW (write address), W (write data), and B (write response). That third channel is the whole story of this chapter: because nothing comes back from a write except a confirmation, the B channel exists to tell the manager the write landed, and whether it succeeded. We'll walk a write end-to-end, meet the two write-only details the read didn't have — WSTRB byte strobes and a single BRESP — and see why a write that ignores B is a real silicon bug. The deep channel-dependency and deadlock rules are still Module 3; here we follow the path.

1. A Write Is Three Channels — and Why

A write decomposes into three one-directional channels:

AW (manager → subordinate): the write address and attributes — where and how much.
W (manager → subordinate): the write data, the byte strobes (WSTRB), and WLAST on the final beat — what to write.
B (subordinate → manager): a single response (BRESP) — did it land, and was it clean?

Compare to the read: a read's answer (the data on R) doubles as its acknowledgement, so two channels suffice. A write sends data out and gets nothing back but a verdict — so it needs a dedicated B channel to carry that verdict. The presence of B is the structural difference between a write and a read, and the reason is simply that you cannot confirm a write by its (non-existent) return data.

2. The Write Address Channel (AW)

AW carries the write's intent, mirroring AR on the read side: the write address plus AWLEN (how many beats), AWSIZE (beat width), AWBURST (burst type), AWID (transaction ID), and protection/cache attributes. One AW handshake launches one write transaction, which may carry many beats of data on W.

As on the read side, AW carries no data — it is purely the request. And one AW can describe a whole burst: AWLEN says how many W beats this single address will be followed by.

3. The Write Data Channel (W) — and WSTRB

W carries the payload, and it introduces the first thing the read path didn't have — byte strobes:

WDATA — the data for this beat.
WSTRB — byte-lane strobes: one bit per byte of WDATA, marking which bytes in this beat are actually written. This is how AXI does partial / sparse writes — writing a single byte into a wide bus means asserting one strobe bit and leaving the rest deasserted. A read has no equivalent, because a read always returns full beats; only a write can be partial.
WLAST — asserted on the final W beat, marking the end of the write data, exactly as RLAST did for reads.

So the manager streams W beats, each selecting its valid bytes with WSTRB, and raises WLAST on the last one. WSTRB is worth flagging now because forgetting it — or driving it wrong — silently corrupts memory in a way that's invisible until something reads the bytes back.

4. The Write Response Channel (B)

B is the channel a write cannot do without. After the subordinate has accepted the write data, it drives one response on B:

BRESP — the response code (OKAY / EXOKAY / SLVERR / DECERR) for the whole write transaction. Note one response per write — unlike the read's per-beat RRESP — because a write is acknowledged as a single completed operation, not beat by beat.
BID — identifies which transaction this response belongs to (matching the AWID), so responses can be paired with their writes even when several are outstanding.

The manager accepts the response with BREADY, and only then is the write complete. A write isn't "done" when the last data beat goes out — it's done when B comes back confirming the subordinate took it.

Figure 1 — a 4-beat burst write, time downward. One AW handshake launches the write; the manager then streams four W beats (each with WSTRB byte-enables), asserting WLAST on the last; finally the subordinate returns a single B response (BRESP) confirming the whole write. Three channels, one transaction.

5. A Single-Beat Write, End to End

Drop to the cycle level for the simplest write — one beat — and watch all three handshakes in sequence.

valid / ready (per channel)

AXI4 single-beat write — AW → W → B

12 cycles

Address accepted on AW, data (wlast=1) accepted on W, then the subordinate's bresp=OKAY accepted on B. Only after B does the manager know the write landed.

Figure 2 — a single-beat AXI write. The address transfers on the AW handshake (awvalid & awready); the data transfers on the W handshake (wvalid & wready, with wlast=1); then the subordinate returns the response on the B handshake (bvalid & bready, bresp=OKAY). The write is complete only when B is accepted.

Walking it: the manager drives awvalid with the address and the subordinate raises awready — the address is accepted. The manager drives wvalid with wdata, wstrb, and wlast=1, and the subordinate raises wready — the data is accepted. After it has taken the data, the subordinate drives bvalid with bresp, the manager accepts with bready — the response is accepted and the write is now complete. Three handshakes, in order, and the transaction isn't finished until the third.

6. The Write Lifecycle

At the transaction level a write is a short sequence with a burst loop in the middle, ending on B:

Figure 3 — the write lifecycle. After the AW handshake the manager streams W beats, looping until the beat carrying WLAST; the subordinate then returns a single B response, and only accepting B completes the write. A single-beat write takes the W loop exactly once.

A write monitor follows exactly this shape — capture the address on AW, collect W beats until WLAST, then pair the single B response:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — reconstruct one write transaction from its three channels.
if (awvalid && awready)               // AW handshake: write launched
  addr = awaddr;
 
if (wvalid && wready) begin           // each W handshake: one data beat
  beats.push_back('{wdata, wstrb});   // capture data + which bytes are valid
  if (wlast) data_done = 1;           // WLAST ends the data phase
end
 
if (bvalid && bready)                 // B handshake: the verdict
  complete_write(addr, beats, bresp); // pair the single response to the write

Note the asymmetry with the read monitor: a read completed on RLAST; a write isn't complete until the separate B handshake, which is the extra step the third channel forces.

7. Read vs Write — Why the Extra Channel

The cleanest way to lock this in is to put the two paths beside each other. They share the AW/AR request idea and the data-with-LAST idea; they differ entirely in how completion is signalled.

Figure 4 — read versus write, side by side. A read's completion rides on its returning data (RLAST on R), so two channels suffice. A write sends data out and gets nothing back but a verdict, so it needs a third channel — B — to carry the single response. The extra channel is not overhead; it is the only way to confirm a write.

8. Common Misconceptions

Myths to unlearn

"A write is done when the last data beat is sent." No — a write completes only when the B response is returned and accepted. Until B, the manager doesn't know (and shouldn't assume) the write landed.
"BRESP is per beat, like RRESP." BRESP is one response for the whole write transaction. A read reports per beat on R; a write reports once on B. Don't expect a response per W beat.
"You can ignore B." A manager that fires writes and never checks BRESP will silently miss SLVERR/DECERR — a real bug class where corrupted or mis-routed writes surface far downstream. B exists to be read.
"Every byte in a W beat is written." Only the bytes whose WSTRB bit is set are written. WSTRB enables partial/sparse writes; mis-driving it corrupts memory invisibly. Reads have no such concept.
"The data must arrive after the address." The channels are independent — W data can be presented before, with, or after AW in AXI4. The hard ordering is only that B must follow the write data, never precede it. (The full dependency rules are Module 3.)

9. Debugging Insight

🔍 Debugging insight — a write is three handshakes; B is where the truth is

On a capture, a write is three handshake events, and the failures cluster by which one is missing or wrong:

AW handshake. awvalid never high → the manager didn't issue the write. awvalid high but awready stuck low → the subordinate/interconnect isn't accepting the address.
W handshake(s) and WLAST. Data beats not advancing → the subordinate isn't ready (wready low) or the manager stalled. A burst that never asserts WLAST leaves the data phase open and the write never reaches B.
B handshake — read it, don't skip it. This is where most "the write seemed fine but data is wrong" bugs live. Check BRESP: DECERR means the address routed to no subordinate (fix the address/map); SLVERR means a real subordinate rejected the write (read-only region, bad size, internal fault). And if bvalid stays high with bready low, the manager isn't draining its responses — its writes back up.

The single most valuable habit: always look at B. A write that "worked" on AW and W but returned SLVERR did not land — and a master that never checks B will propagate that corruption silently.

10. Verification Insight

✅ Verification insight — the write monitor pairs three channels, and WSTRB is the catch

A write monitor reconstructs the transaction from three channels: capture the address/AWLEN on AW, collect each wdata+wstrb on W until wlast, then pair the single B response (matched by BID). The checks that follow: the W beat count matches AWLEN + 1, the data phase ends with WLAST, exactly one BRESP returns and is legal/expected, and — the write-specific one — the reference memory is updated only on the bytes WSTRB selected. That last check is the common miss: a scoreboard that ignores WSTRB will disagree with the DUT on partial writes, or worse, hide a real strobe bug.

Coverage wants varied burst lengths, every BRESP code, partial writes (sparse WSTRB patterns), and outstanding/back-to-back writes. The write path is the read path plus a response channel to pair and byte-strobes to honour — which is exactly the two things to get right. Full mechanics are Module 16.

11. Interview Questions

12. Summary

A write is three channels because it returns no data: the manager launches it on AW (address + AWLEN), streams the payload on W (data + WSTRB byte strobes + WLAST), and the subordinate confirms with one response on B (BRESP, matched by BID). The write is complete only when B is accepted — not when the last data beat goes out — and that third channel exists precisely because, unlike a read, there is no returning data to serve as the acknowledgement.

Two write-only details separate this path from the read: WSTRB, which selects the valid bytes per beat and enables partial writes (mis-drive it and memory corrupts silently), and the single BRESP on B, which a manager must actually check — SLVERR/DECERR mean the write didn't land. Read a write off a waveform as three handshakes ending on B; reconstruct it as capture address, collect beats to WLAST, pair the B response, honour WSTRB; and debug it by always looking at B. Reads and writes now both walk end-to-end — next we make explicit why keeping these channels independent is what makes AXI fast.

13. What Comes Next

You've followed both a read and a write end-to-end. Module 2 now turns to the property that makes those channels powerful:

2.4 — Independent Channels & Decoupling (coming next) — why address, data, and response are decoupled, and the throughput that decoupling unlocks.
2.5 — AXI4 vs AXI3 vs AXI4-Lite vs AXI4-Stream (coming soon) — the four variants and when each applies.

Previous: 2.2 — The Read Path. For the broader protocol catalog, see the AMBA family overview doc.