AMBA AXI · Module 4

The Write Response (B) Channel

Why an AXI write needs an explicit response — the B channel, BRESP and BID, one response per transaction, the B-after-W ordering, and the B handshake.

A write isn't finished when the last data beat goes out — it's finished when the B (write response) channel confirms it. AW declared the write and W delivered the bytes, but neither tells the manager whether the write actually landed. That's the B channel's job: a single response per write, carrying BRESP (success or failure) and BID (which write it answers). This chapter explains why a write needs a separate response (when a read doesn't), what B carries, the one-response-per-transaction rule, and the B-after-W ordering. The full BRESP code decode and arrival timing is Chapter 4.5; here it's the B channel and its role as the write's acknowledgement.

1. Why a Write Needs an Explicit Response

Recall the asymmetry from Chapter 2.3: a read gets its acknowledgement for free — when the data returns on R, the read happened, and RRESP rides along per beat. A write sends data out and gets nothing back as a natural by-product. Without a dedicated channel, the manager would have no way to know the write reached its target, was accepted, and succeeded. So the write needs an explicit, separate B channel to carry that verdict.

This is the structural reason a write has three channels and a read has two. The B channel exists precisely because there is no returning data to serve as the acknowledgement — so AXI provides a one-beat response channel instead.

Figure 1 — why the write needs B. A read's returning data on R is itself the acknowledgement (with RRESP per beat), so two channels suffice. A write sends data out on W and gets nothing back, so it needs a separate B channel to report whether the write landed and succeeded. B is the write's only acknowledgement.

2. What B Carries

The B channel is small — one beat per write, two payload signals plus the handshake:

BRESP — a 2-bit response code for the whole write: OKAY, EXOKAY, SLVERR, or DECERR. (Same encoding as the read's RRESP. The full decode and when each applies is Chapter 4.5.)
BID — the transaction identifier, matching the AWID of the write being answered, so the manager knows which outstanding write this response belongs to.
BVALID / BREADY — the handshake: the subordinate drives BVALID with the response; the manager accepts with BREADY.

Figure 2 — the B channel's signals. BRESP carries the success/failure verdict for the whole write; BID identifies which write it answers (matching the AWID); BVALID/BREADY transfer the single response beat. The slave is the source here (B flows subordinate→manager), unlike AW and W.

3. One Response Per Write — Not Per Beat

A crucial contrast with the read path: B carries exactly one response for the entire write transaction, no matter how many W beats it had. A 256-beat write gets one BRESP. This differs from a read, where RRESP is reported per R beat.

The reason is structural. A read's status travels with the data (many beats, each possibly meeting a different condition), so per-beat makes sense. A write is acknowledged as a single completed operation — the subordinate takes all the data, then issues one verdict — so one BRESP suffices and is all you get. Don't look for a response per W beat; there isn't one.

4. B Must Follow W

The B channel obeys the mandatory ordering from Chapter 3.5: the subordinate must not assert BVALID until it has accepted the write data — specifically, after the W-channel handshake of the last beat (WLAST). A response before the data is a protocol violation, and a dangerous one: the manager would see OKAY and believe a write landed that the subordinate never actually took.

So the causal chain is fixed: AW (and W) → all W beats accepted (WLAST) → then B. The subordinate may legally wait for the address too, but the hard rule is B-after-the-write-data. And only when the manager accepts B (BVALID && BREADY) is the write truly complete — not when WLAST went out, but when the response is consumed.

5. The B Handshake

After the write data is accepted, the subordinate drives BVALID with BRESP/BID; the manager accepts with BREADY.

B response — completing the write

8 cycles

Figure 3 — the B response handshake. After the final W beat (WLAST) is accepted, the subordinate raises BVALID with BRESP=OKAY; the manager accepts with BREADY, and the write completes at that edge. BVALID must not precede the accepted write data (B-after-W), and the write is done only when B is accepted — not when WLAST went out.

The handshake rules from Module 3 all apply: BVALID must not wait for BREADY (cardinal rule), the response must stay stable while waiting (stability), and a manager that never asserts BREADY jams the channel (the drain bug from 3.6). Many simple masters tie BREADY high to always drain responses.

6. BID Pairs the Response to Its Write

When a manager has multiple writes outstanding, the responses come back on the single B channel — and BID is how it knows which is which. Each BVALID carries the BID of the write it completes, matching the AWID the manager issued. Responses for different IDs may return out of order; BID lets the manager pair each one correctly.

Figure 4 — BID pairing with outstanding writes. The manager launches write A (AWID=0) and write B (AWID=1) before either completes; the subordinate returns responses on the single B channel tagged with BID, which may arrive in either order. BID=0 retires write A, BID=1 retires write B. Without BID, a manager couldn't tell whose response is whose.

In code, consuming a response means checking BRESP and retiring the matching transaction:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — consume the write response and pair it to its transaction.
if (bvalid && bready) begin
  if (bresp != OKAY) note_write_error(bid, bresp);  // SLVERR/DECERR: it did NOT land
  retire_write(bid);                                // BID matches the AWID issued
end

7. Common Misconceptions

Myths to unlearn

"A write is done when the last data beat is sent." No — it completes only when the B response is accepted (BVALID && BREADY). Until B, the manager doesn't know the write landed.
"BRESP is per beat like RRESP." BRESP is one response for the whole write transaction, regardless of beat count. Only reads report status per beat.
"You can ignore BRESP." A SLVERR/DECERR means the write did not succeed. A manager that never checks BRESP silently misses failed/mis-routed writes — a real corruption bug class.
"The slave can respond as soon as it has the address." BVALID must follow the accepted write data (WLAST), not just the address (B-after-W). Responding early is a protocol violation.
"BID is unnecessary if there's one write at a time." For a strictly in-order single-outstanding master, BID may be constant — but in general it's how out-of-order, multi-outstanding responses are paired to their writes.

8. Debugging Insight

🔍 Debugging insight — B is where a write's truth lives

When a write misbehaves, the B channel is the first place to look for the verdict — many "the write seemed fine" bugs are actually visible on B:

Did B come back at all? If the write data was accepted (WLAST) but BVALID never rises, the write is stuck in the subordinate (or never reached one). If BVALID is high but BREADY is low forever, the master isn't draining responses (the drain bug from 3.6) — and subsequent writes back up behind it.
Read BRESP. OKAY means it landed; SLVERR means a real subordinate rejected it (read-only region, bad size, internal fault); DECERR means the address routed to no subordinate (fix the address/map). A write that "completed" with SLVERR/DECERR did not land — chase that, not the data path.
Check BID against the issued AWIDs. A BID that matches no outstanding write, or pairs to the wrong one, is a response-routing bug (often in an interconnect). It can make a manager retire the wrong transaction.
Check ordering. A BVALID that appeared before the matching write's WLAST is a B-after-W violation — the response preceded the data.

The discipline: a write's success is defined by its B response, so read BRESP/BID before trusting that any write happened.

9. Verification Insight

✅ Verification insight — the scoreboard closes the write on B

A write isn't checked complete until its B response is verified, so the scoreboard pairs B to the write it issued: it matches BID to the outstanding AWID, confirms exactly one BRESP is returned per write (never per beat, never zero, never duplicated), checks the response code is the expected one (e.g. a write to an unmapped address should return DECERR; a write to a read-only region should return SLVERR), and enforces the B-after-W ordering (BVALID only after the accepted WLAST). Negative testing matters here — deliberately target bad addresses/regions and assert the correct error response, since a subordinate that returns OKAY for a failed write is a serious bug a happy-path test never finds.

Protocol assertions bind to B as before: handshake stability/cardinal-rule, a liveness/timeout so an asserted BVALID is eventually accepted (catches the master-not-draining hang) and every accepted write eventually gets a B (catches a lost response). Coverage wants every BRESP code seen and responses paired across multiple outstanding IDs in and out of order. Mechanics in Module 16.

10. Interview Questions

11. Summary

The B channel is a write's acknowledgement — it exists because, unlike a read, a write returns no data to confirm itself. B carries BRESP (one success/failure code — OKAY/EXOKAY/SLVERR/DECERR — for the whole transaction, not per beat) and BID (matching the write's AWID, so responses pair to their writes even when several are outstanding and return out of order), moved by the BVALID/BREADY handshake. It obeys B-after-W: the subordinate may assert BVALID only after accepting the write data (WLAST), and the write is complete only when B is accepted — not when the last beat went out.

Treat B as the source of truth for a write: read BRESP (a non-OKAY means the write did not land — ignoring it is a real bug class), check BID pairing, and watch for the drain hang (BVALID high, BREADY low forever). Verify by closing each write on B — one expected response per transaction, correct codes including negative cases, and B-after-W ordering. With AW, W, and B all detailed, Module 4 turns next to the ordering and WLAST rules that tie the write path together.

12. What Comes Next

The three write channels are covered; next is how they're ordered and bounded:

4.4 — Write Ordering & WLAST (coming next) — WLAST, AW↔W ordering, and the AXI3→AXI4 WID change in depth.
4.5 — BRESP & Write Response Timing (coming soon) — decoding BRESP and exactly when B may arrive.

Previous: 4.2 — The Write Data (W) Channel. For the broader protocol catalog, see the AMBA family overview doc.