AMBA AXI · Module 17

BRESP / RRESP Errors

Interpret and trace AXI error responses — what SLVERR and DECERR each mean, the decisive distinction (the slave faulted vs. no slave was there), how to follow an error back to its root cause through the interconnect decode and the slave's error logic, and why an error response is a clue to follow, not a failure in itself.

The data-corruption chapters (17.2–17.4) dealt with bugs that produce wrong data with an OKAY response. This chapter is the inverse: the response itself signals a problem. BRESP (write) and RRESP (read) carry a 2-bit status — OKAY, EXOKAY, SLVERR, DECERR — and an error response (SLVERR/DECERR) is the bus telling you something went wrong. The skill is interpreting which error and tracing it to its root cause: DECERR and SLVERR mean very different things and point at different parts of the system. Crucially, an error response is often correct behavior (the slave properly rejecting a bad access) — so the question is rarely "why did the bus error?" but "is this error expected, and if not, what produced it?" This chapter decodes the response codes and gives the method to trace each to its source.

1. The Four Response Codes

BRESP/RRESP encode four states. OKAY (2'b00) — normal successful access. EXOKAY (2'b01) — exclusive access succeeded (read/write pair held). SLVERR (2'b10) — the slave was reached but the access failed at the slave (write to read-only, reserved offset, internal error, unsupported request). DECERR (2'b11) — the decode failed: no slave exists at that address (the interconnect's default slave responds). The decisive split is SLVERR vs. DECERR: a slave faulted versus no slave was there at all.

Figure 1 — the four AXI response codes and what each means. OKAY: normal success. EXOKAY: exclusive access succeeded. SLVERR: the slave was reached but the access failed at it (read-only write, reserved offset, internal fault). DECERR: address decode failed — no slave exists there, and the interconnect's default slave returns it. The key diagnostic split is SLVERR (a slave faulted) vs. DECERR (no slave was there), which point at different parts of the system.

2. DECERR: No Slave Was There

DECERR means the address didn't decode to any slave — the interconnect's decoder found no match in the address map and routed the access to the default slave, which returns DECERR. The root cause is almost always on the address/decode side: software (or a master) issued an access to an unmapped address, or the interconnect's address map is wrong/incomplete (a slave's region misconfigured, a gap in the map). Tracing a DECERR means checking the requested address against the address map: is the address genuinely unmapped (a master/software bug) or should it have matched a slave (a decode/map bug)?

Figure 2 — tracing a DECERR. The access address is compared against the interconnect's address map. If it matches no slave region, the decoder routes it to the default slave, which returns DECERR. Trace the root cause by checking the address against the map: a genuinely-unmapped address means a master/software bug (bad address issued); an address that should have matched means a decode/address-map bug (misconfigured region or a gap). DECERR points at the address and the decode, not at any real slave.

3. SLVERR: The Slave Reached, But Failed

SLVERR means the access reached a real slave but the slave rejected or failed it. The root cause is inside the slave, and the specific reasons are slave-defined: a write to a read-only register, an access to a reserved offset, an unsupported request (e.g. a burst type the slave doesn't handle, an exclusive access it can't satisfy), or an internal fault (ECC error, a downstream timeout the slave converts to SLVERR). Tracing a SLVERR means asking the slave why it rejected this specific access — which register/offset, which condition — and that's read from the slave's spec and its error logic, not the decode.

SLVERR — write to a read-only register

10 cycles

Figure 3 — a SLVERR on a write to a read-only register. The write address handshakes and the data transfers normally (the slave is reached), but the target is a read-only register, so the slave returns BRESP=SLVERR and does not modify the register. A following write to a valid RW register returns OKAY. The SLVERR is the slave correctly rejecting an illegal access — the trace leads into the slave's access-type/error logic and its spec, not the interconnect decode.

4. An Error Is a Clue, Not a Verdict — Expected vs. Unexpected

The crucial mindset: an error response is not automatically a bug — it's the bus reporting a condition, and that condition may be exactly what should happen (a negative test, 16.7, deliberately provokes SLVERR/DECERR). So the first diagnostic question is was this error expected? The reference model (16.4) predicts the expected response for every access (it knows the address map and access types), so an unexpected error — one the model predicted OKAY for — is the real bug, while an expected error confirms correct rejection. An unexpected DECERR means the address went wrong or the map is misconfigured; an unexpected SLVERR means the slave faulted on an access it should have accepted.

Figure 4 — expected vs. unexpected error responses. The reference model predicts the response for every access from the address map and access types. Compare the actual response to the prediction: a predicted error that occurs is correct behavior (e.g. a negative test); an unexpected error (model predicted OKAY, bus returned SLVERR/DECERR) is the bug to trace — DECERR to the address/decode, SLVERR to the slave's error logic. An error response is a clue to follow, classified first as expected or not.

5. Common Misconceptions

Myths to unlearn

"An error response means there's a bug." Not necessarily — SLVERR/DECERR may be exactly correct (the slave properly rejecting a read-only write, the decoder properly returning DECERR for an unmapped access). The first question is was this error expected?, answered by the reference model — an error is a clue, not a verdict.
"SLVERR and DECERR are interchangeable error codes." They mean different things and point at different places: DECERR = decode failed, no slave there (trace the address/map); SLVERR = a slave was reached but the access failed (trace the slave's logic). Conflating them sends you debugging the wrong part of the system.
"DECERR means the slave is broken." No — DECERR comes from the default slave because no real slave matched the address. The fault is on the address/decode side (bad address or wrong map), not in any actual slave.
"A SLVERR is the interconnect's fault." Usually not — SLVERR originates inside the slave that was reached (read-only write, reserved offset, internal fault). The interconnect just forwards it. Trace into the slave, not the fabric.
"The error code tells you the full cause." It tells you the category (decode vs. slave) and the direction to trace, not the specific cause. A SLVERR still needs you to ask the slave which access-type/offset/fault triggered it; a DECERR needs you to check which address and why it didn't map.
"Errors don't need to be in the scoreboard's prediction." They must — the reference model has to predict the expected response (including expected errors) so you can distinguish expected from unexpected. A scoreboard that only checks data, not response codes, can't tell a correct rejection from a real fault.

6. Debugging Insight

🔍 Debugging insight — classify expected/unexpected first, then trace by code

Diagnose an error response in two steps — classify, then trace:

Was the error expected? Check the reference model's prediction for this access. If the model predicted the same error, it's correct behavior (e.g. a negative test) — not a bug. Only an unexpected error (model predicted OKAY) is the bug to chase. This step prevents the most common waste: debugging a correct rejection.
DECERR (unexpected) → trace the address and decode. Check the requested address against the address map: is it genuinely unmapped (a master/software bug issuing a bad address) or should it have matched a slave (a decode/address-map bug — misconfigured region, map gap)? DECERR always points at the address side.
SLVERR (unexpected) → trace into the slave. Identify which slave the address mapped to, then ask its error logic why: read-only write? reserved offset? unsupported burst/exclusive? internal fault (ECC, downstream timeout converted to SLVERR)? The slave's spec and error conditions are the source.
Per-beat RRESP differences. On reads, each beat has its own RRESP, so a burst can be OKAY then SLVERR/DECERR mid-burst (e.g. crossing from a mapped into an unmapped region). The beat where the code changes localizes the boundary — check the address at that beat.
Intermittent errors under load. A SLVERR that appears only under certain conditions often reflects an internal slave fault (a downstream timeout, a resource exhaustion) converted to SLVERR, not a static access-type issue. Correlate with the slave's internal state.
The error response is correct but recovery is wrong. Distinct from this chapter's scope — even a correct SLVERR must leave state unchanged and the bus must recover (17.x/16.7); a correct code with broken recovery is still a bug, just not a response-interpretation one.

The method is classify (expected via the model) → trace by code (DECERR to address/decode, SLVERR to slave logic). The code tells you which half of the system to investigate; the model tells you whether to investigate at all.

7. Verification Insight

✅ Verification insight — predict every response, distinguish expected from unexpected, and trace by code

Response-code verification rests on the reference model predicting the response for every access, because an error is only a bug if it's unexpected. Disciplines: (1) The reference model predicts OKAY/SLVERR/DECERR/EXOKAY from the address map (for DECERR) and the slave's access-type/error spec (for SLVERR/EXOKAY), so the scoreboard (16.4) compares actual vs. predicted response code, not just data — this is what separates a correct rejection from a real fault, and a scoreboard that ignores response codes is blind to this entire bug class. (2) The two codes route the trace — DECERR is a decode/address problem (check the address against the map: bad address vs. wrong map), SLVERR is a slave problem (check the slave's error logic: read-only, reserved, unsupported, internal fault); building this routing into the debug flow (and into the error messages, which should report the code, address, and mapped slave) makes localization immediate. (3) Per-beat RRESP must be predicted and checked per beat, since a read burst can change response code mid-burst at a region boundary. (4) Negative testing (16.7) is the source of expected errors — deliberately provoking SLVERR (read-only write) and DECERR (unmapped access) and confirming the model predicted them validates both the error generation and the prediction, so the expected/unexpected classification is itself verified. (5) Coverage must include the error responses — an OKAY-only run has never exercised the error paths, so the error-response coverage bins (16.5) must be hit, which requires the negative tests. The framing that ties it together — an error response is a clue, not a verdict — is the response-channel instance of the protocol-checker mindset (16.1): the bus is reporting a condition, and verification's job is to know the expected condition (via the model) and flag only the deviation. The highest-value, easiest-to-miss mistake is treating any error as a failure (wasting time debugging correct rejections) or, worse, treating an unexpected error as noise (missing a real bug because "errors happen") — both are avoided by always predicting the response and comparing. This chapter shifts the debugging focus from the data/burst signals (17.1–17.4) to the status signal: the response code is the design telling you something, and reading it correctly — expected vs. unexpected, then DECERR vs. SLVERR — is a distinct and essential debugging skill. Next, we trace a different routing problem: responses delivered to the wrong ID.

8. Interview Questions

9. Summary

BRESP/RRESP carry a 2-bit status — OKAY (success), EXOKAY (exclusive succeeded), SLVERR (a real slave was reached but the access failed), DECERR (the address decoded to no slave; the default slave responds) — and the decisive split is SLVERR vs. DECERR: a slave faulted versus no slave was there. The two codes route the trace to different halves of the system: DECERR → the address/decode (bad address from a master/software, or a wrong/incomplete address map), and SLVERR → inside the slave (read-only write, reserved offset, unsupported request, or an internal fault like ECC or a converted downstream timeout). On reads, RRESP is per beat, so a burst can change code mid-burst at a region boundary, and the beat where it changes localizes the boundary.

The essential mindset is that an error response is a clue, not a verdict — it may be exactly correct behavior (a negative test, a proper rejection). So the first step is always to classify expected vs. unexpected using the reference model's predicted response (which must predict codes, not just data); only an unexpected error is a bug, and then the code routes the trace. This is the response-channel form of the protocol-checker mindset (16.1): the bus reports a condition, and verification compares it against the expected condition, flagging only deviations — which prevents both debugging correct rejections and ignoring real faults. Verification predicts every response, the scoreboard compares codes, negative tests source the expected errors, and coverage confirms the error paths were exercised. The debugging focus shifts from data/burst signals (17.1–17.4) to the status signal. Next, we trace a routing problem of a different kind: responses delivered to the wrong ID.

10. What Comes Next

You can now interpret and trace error responses; next, responses that go to the wrong place:

17.6 — ID Mismatch (coming next) — diagnosing responses routed to the wrong ID, where the response is fine but it's delivered to the wrong transaction, corrupting the manager's tracking.

Previous: 17.4 — Wrong WSTRB. Related: 6.8 — RRESP, BRESP & RLAST for the response-code semantics, 12.3 — Decode & Address Map for the DECERR decode path, and 16.7 — Negative & Error-Injection Testing for provoking and predicting expected errors.