AMBA AXI · Module 4

BRESP & Write Response Timing

Decode the AXI write response — OKAY, EXOKAY, SLVERR, DECERR — what each means, SLVERR vs DECERR localization, and exactly when B may arrive.

The B channel (4.3) carries one signal that decides whether a write succeeded: BRESP. This chapter decodes its four values — OKAY, EXOKAY, SLVERR, DECERR — and, just as importantly, teaches what each tells you about where a write went wrong. The SLVERR-vs-DECERR distinction alone localizes a failure to "inside the target" versus "no target at all," saving hours of debugging. We also pin down the timing: when B is allowed to arrive (after the write data, never before) and that there's no upper bound on how long it may take. BRESP shares its encoding with the read channel's RRESP, so this decode applies to both.

1. The Response Decides Success

A write isn't successful because the data went out — it's successful because BRESP says so. BRESP is a 2-bit code returned once per write transaction (4.3), and it is the manager's only authoritative statement that the write reached its target and was accepted. Ignoring it (treating every write as OKAY) is the silent-corruption bug class from earlier chapters; decoding it is how a robust master knows what actually happened.

2. The Four BRESP Codes

`BRESP`	Code	Meaning
`OKAY`	`2'b00`	Normal access succeeded
`EXOKAY`	`2'b01`	Exclusive access succeeded (only for exclusive writes)
`SLVERR`	`2'b10`	Slave error — a real target was reached but it failed the access
`DECERR`	`2'b11`	Decode error — no target exists at that address

Two are success (OKAY, EXOKAY) and two are failure (SLVERR, DECERR). The same encoding is used for the read channel's RRESP, so learning it here covers both directions.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — act on the write response code.
case (bresp)
  2'b00: /* OKAY   */ ;                       // normal success — done
  2'b01: /* EXOKAY */ mark_exclusive_ok();    // exclusive write succeeded
  2'b10: /* SLVERR */ handle_slave_error();   // target rejected — look inside the slave
  2'b11: /* DECERR */ handle_decode_error();  // no slave at addr — fix address / map
endcase

3. OKAY and EXOKAY

OKAY is the normal-success response — the write reached its target, was accepted, and completed. The overwhelming majority of writes return OKAY.

EXOKAY is the success response specifically for an exclusive access. Exclusive accesses (the AXI mechanism for atomic read-modify-write, covered in Module 9) ask "did my exclusive write succeed without another agent intervening?" — and EXOKAY is the "yes, exclusively" answer. Critically, a normal (non-exclusive) write must never return EXOKAY; it returns OKAY. Seeing EXOKAY on a transaction that wasn't an exclusive access is itself a bug. So EXOKAY is not "extra okay" — it's a narrow, exclusive-access-only signal.

4. SLVERR vs DECERR — Where the Write Died

The two error codes are the most valuable diagnostic in AXI, because they tell you where the failure happened:

DECERR (decode error) — the interconnect could not route the address to any subordinate. The target address falls in a hole in the memory map, so the interconnect's default slave answers with DECERR. Meaning: no target exists there. Fix: the address or the memory map — the transaction was aimed at nothing.
SLVERR (slave error) — the address decoded to a real subordinate, but that subordinate rejected the access: writing a read-only register, an unsupported transfer size, a FIFO overflow, an internal fault. Meaning: the target exists but said no. Fix: look inside that subordinate.

Figure 1 — SLVERR vs DECERR localizes the failure. If the address decodes to a real subordinate that then rejects the access (read-only, bad size, internal fault), it returns SLVERR — look inside the target. If the address decodes to nothing, the interconnect's default slave returns DECERR — fix the address or memory map. The code tells you whether the target exists.

The one-line mnemonic: DECERR → fix the address/map (nothing's there); SLVERR → fix the target (it's there but unhappy). A manager that lumps both into "error" loses this localization; keep them distinct.

5. When B May Arrive

BRESP rides the B handshake, and its timing is bounded on one side only:

Earliest: B may assert only after the write data is accepted — i.e., after the WLAST beat's W handshake (the B-after-W rule, Module 3.5). The very soonest a subordinate can drive BVALID is the cycle after WLAST is accepted; it must not be same-cycle-or-earlier, and certainly not before the data.
Latest: there is no fixed upper bound. A subordinate may take as long as it needs (a slow memory, a busy controller) before responding; the manager waits. This is normal — write latency lives here.

Figure 2 — the B timing window. BVALID is forbidden until the write data is accepted (after WLAST); from there it may come the next cycle or many cycles later (the subordinate's processing time). There's a hard lower bound (B-after-W) but no upper bound — a late B is latency, not a bug. A B before WLAST, however, is a protocol violation.

6. The Response on a Waveform

A write that targets an unmapped address: the data is accepted, then the default slave returns DECERR on B.

B response — DECERR on an unmapped write

8 cycles

Figure 3 — a write returning DECERR. The write data is accepted (WLAST), then after the address failed to decode to any subordinate, the interconnect's default slave drives BVALID with BRESP=DECERR; the manager accepts with BREADY. The handshake is perfectly normal — only the code says the write went nowhere. A master that ignores BRESP would treat this failed write as done.

The handshake itself is indistinguishable from a successful one — BVALID/BREADY behave identically. Only the code differs, which is exactly why a master must read BRESP rather than assume success from a completed handshake.

7. Acting on the Code

A robust master routes each code to the right action:

Figure 4 — decoding BRESP into action. OKAY: proceed. EXOKAY: the exclusive write succeeded (only valid for exclusive accesses). SLVERR: the target rejected the write — investigate inside that subordinate. DECERR: the address mapped to nothing — fix the address or memory map. Each code points at a different fix.

8. Common Misconceptions

Myths to unlearn

"A completed B handshake means the write succeeded." No — the handshake completing only means the response was delivered. Success is the code (OKAY/EXOKAY); SLVERR/DECERR mean it failed. Always read BRESP.
"SLVERR and DECERR are the same 'error'." They localize differently: DECERR = no subordinate at that address (fix the map); SLVERR = a real subordinate rejected the access (fix the target). Collapsing them throws away the most useful diagnostic.
"EXOKAY is a 'better OKAY'." EXOKAY is only for successful exclusive accesses. A normal write returns OKAY; a normal write returning EXOKAY is itself a bug.
"B can come as soon as the address is accepted." B must follow the write data (after WLAST), not just the address. B before the data is a protocol violation.
"A slow B response is a bug." There's no upper bound on B timing — a late response is just write latency (a slow memory/controller). Only B before WLAST, or a B that never comes, is wrong.

9. Debugging Insight

🔍 Debugging insight — the code tells you where to look next

When a write fails, BRESP points you straight at the right place — don't debug a failed write without reading it:

DECERR? The address decoded to nothing — the interconnect's default slave answered. Don't look inside any peripheral; check the address and the memory map. Common causes: a mis-computed address, an unmapped region, a base-address misconfiguration, an address that should have gone somewhere else.
SLVERR? A real subordinate rejected the write — look inside that target. Common causes: writing a read-only register, an unsupported AWSIZE/burst for that slave, a FIFO/buffer overflow, or an internal error condition. The interconnect and address are fine; the target said no.
OKAY but data still wrong? The write landed successfully, so the bug isn't B — look at WSTRB (partial-write masking, 4.2) or ordering/pairing (4.4). OKAY rules out the response path.
No B at all (after WLAST)? Not a code problem — the response is missing: the subordinate is stuck or the master isn't draining BREADY (the hang from 3.6/4.3).

The mnemonic again: DECERR → address/map; SLVERR → inside the target; OKAY+wrong-data → strobes/ordering. The code is the first thing to read and it cuts the search space immediately.

10. Verification Insight

✅ Verification insight — negative testing is where BRESP earns its keep

Happy-path tests only ever see OKAY, so the error codes are verified by deliberate negative testing: write to an unmapped address and assert DECERR; write to a read-only region or with an unsupported size and assert SLVERR; perform an exclusive write and assert EXOKAY on success (and OKAY/failure semantics when the monitor was lost). The scoreboard must check the expected code per scenario, not just "is it OKAY" — a subordinate that returns OKAY for a write it actually rejected is a serious bug a positive test never catches. Coverage wants every BRESP value observed, including EXOKAY only on exclusive accesses and never on normal ones.

Timing gets assertions too: BVALID must not assert before the WLAST beat is accepted (B-after-W), and a liveness/timeout catches a B that never arrives — but the check must not impose a false upper bound, since slow responses are legal. So model arbitrary B latency in the responder agent (random delay after WLAST) to ensure the master tolerates late responses. Mechanics in Module 16.

11. Interview Questions

12. Summary

BRESP is the 2-bit verdict on a write, returned once per transaction: OKAY (normal success), EXOKAY (exclusive-access success only — never for normal writes), SLVERR (a real target rejected the access), and DECERR (no target at that address; the interconnect's default slave answered). The error pair is the key diagnostic: DECERR → fix the address/map (nothing's there); SLVERR → fix the target (it's there but refused). The same encoding serves the read channel's RRESP.

Timing is bounded below and open above: B may assert only after the write data is accepted (B-after-W) and may then come the next cycle or arbitrarily later — a slow B is latency, not a bug; only a B before WLAST, or one that never arrives, is wrong. Because the B handshake looks identical regardless of code, a master must read BRESP (a completed handshake ≠ success), and verification must negatively test each code rather than only the happy path. With the response decoded, Module 4 closes by assembling the whole write on annotated waveforms.

13. What Comes Next

The write path's mechanics are complete; next, see them all together:

4.6 — Write Transaction Waveforms (coming next) — annotated end-to-end write waveforms: single, burst, and stalled.

Previous: 4.4 — Write Ordering & WLAST. For the broader protocol catalog, see the AMBA family overview doc.