AMBA AHB · Module 12

Simplified Responses

AHB-Lite's OKAY/ERROR-only response model — SPLIT and RETRY are removed because they exist only to release the bus to other masters; a slow slave instead inserts HREADY wait states. Delay is orthogonal to the response: HREADY handles timing, HRESP says only success or failure.

Chapter 12.3 removed arbitration; this chapter covers a direct consequence: AHB-Lite's simplified response model. Full AHB has four HRESP codes — OKAY (success), ERROR (failure), and SPLIT/RETRY (which let a slave release the bus to other masters while it isn't ready). AHB-Lite keeps only OKAY and ERROR. SPLIT and RETRY are removed for the now-familiar reason: they exist only to coordinate multiple masters (releasing the bus so others can proceed), and with one master there's no one to release the bus to. So how does a slow AHB-Lite slave handle a delay? With wait states — holding HREADY low — exactly as any AHB slave does for short delays. The key idea: delay is orthogonal to the response. HREADY handles timing (how long the transfer takes); HRESP says only outcome (success or failure). This chapter covers the OKAY/ERROR model, why SPLIT/RETRY are unnecessary, and the wait-states-handle-delay principle.

1. What Is It?

AHB-Lite's simplified response model is the reduction of HRESP from four codes to two:

OKAY — the transfer succeeded.
ERROR — the transfer failed (the standard two-cycle ERROR response).
~~SPLIT~~ — removed (released the bus to other masters; resumed later).
~~RETRY~~ — removed (released the bus; master retries later).

Figure 1 — the response model narrows from four codes to two. Full AHB (left) has OKAY (success), ERROR (failure), and SPLIT/RETRY (which release the bus to other masters). AHB-Lite (right) keeps only OKAY and ERROR; SPLIT/RETRY are removed because they exist only to coordinate multiple masters. A slow AHB-Lite slave instead holds HREADY low (wait states). Delay is handled by wait states, not a response code.

So the simplified response model means an AHB-Lite slave answers every transfer with just success (OKAY) or failure (ERROR) — and if it needs time, it inserts wait states (HREADY low) rather than using a SPLIT/RETRY response. SPLIT and RETRY were never about success/failure; they were about bus management in a multi-master system (a slow slave handing the bus back so others could use it during the wait). With one master, that bus management is pointless — there's no other master to hand the bus to. So those two codes vanish, leaving the clean OKAY/ERROR outcome model. So AHB-Lite's responses are just: it worked, or it didn't — with wait states for "give me more time."

2. Why Does It Exist?

The simplified response model exists because SPLIT and RETRY are purely multi-master bus-management mechanisms — not transfer outcomes — and a single master makes their purpose (releasing the bus to others) vacuous, while the genuinely-needed capabilities (signal success, signal failure, take more time) are fully covered by OKAY, ERROR, and wait states.

The SPLIT/RETRY purpose is bus-release — recall what they do in full AHB. A slave that can't complete a transfer promptly (e.g. a slow memory that will take many cycles, or one busy serving something else) faces a choice: stall the master (hold HREADY low for the whole delay — but that ties up the bus, blocking other masters), or release the bus so other masters can use it during the wait. SPLIT and RETRY are the release option: RETRY tells the master "abandon this transfer and retry later" (the bus frees up meanwhile); SPLIT is similar but the slave remembers the master and signals the arbiter (via HSPLIT) when ready, so the arbiter re-grants that master. Both release the bus to other masters during a long wait — a multi-master throughput optimization. So SPLIT/RETRY exist to avoid one slow slave monopolizing the shared bus against other masters. So their entire purpose is multi-master bus management.

The single master makes release pointless: with one master, holding the bus during a wait blocks no one — there are no other masters who'd use the freed bus. The single master can't do anything else anyway while waiting (it has no other bus to use, and it's a single thread of bus activity). So releasing the bus gains nothing. So the reason for SPLIT/RETRY — freeing the bus for others — evaporates. So with one master, the slave should just stall the master with wait states (HREADY low) until ready; there's no downside (no other master is blocked). So SPLIT/RETRY are removed because their benefit is zero with one master. So the response model drops them.

The remaining needs are fully covered: what does a slave genuinely need to communicate? Three things: "done, succeeded" (→ OKAY), "done, failed" (→ ERROR), and "not done yet, give me more time" (→ wait states, HREADY low). None of these is SPLIT/RETRY. OKAY and ERROR cover the two outcomes; wait states cover delay. SPLIT/RETRY covered a fourth thing — "I'll be a while; let others use the bus" — which is the only one that's multi-master-specific and thus unneeded. So the OKAY/ERROR + wait-states model covers every single-master need. So the simplified response model exists because SPLIT/RETRY are purely multi-master bus-management (vacuous with one master), while success/failure/delay — the real needs — are fully handled by OKAY/ERROR/wait-states. The deeper principle: delay and outcome are orthogonal. Full AHB partly conflated them (SPLIT/RETRY mixed "I need time" with "let others use the bus"); AHB-Lite cleanly separates them — HREADY for delay (timing), HRESP for outcome (success/failure) — which is simpler and complete for one master. So the simplification both removes the vacuous codes and clarifies the model.

3. Mental Model

Model the simplified responses as a single-lane drive-through versus a multi-lane one — at a busy multi-lane drive-through, if your order will take a while, the attendant asks you to pull forward to a waiting spot so the other lanes keep moving (that's SPLIT/RETRY — releasing your spot for others); but at a single-lane drive-through with only one car ever, there's no point pulling forward — there's no one behind you — so you just wait at the window until your order's ready (wait states), and the attendant only ever tells you "here's your order" (OKAY) or "sorry, we can't make that" (ERROR).

At a multi-lane drive-through (full AHB, multiple masters), the shared windows serve many cars. If your order will take a while, the attendant doesn't make you block the window — they ask you to pull forward to a waiting spot so cars in other lanes (other masters) keep being served, and they'll bring your order out when it's ready (SPLIT) or have you loop around and re-order (RETRY). This releasing of your spot exists to keep the other lanes flowing. Now a single-lane drive-through (AHB-Lite, one master) where you're the only car that ever comes: if your order takes a while, there's no point pulling forward — there's no one behind you to unblock — so you simply wait at the window until it's ready (wait states, HREADY low). The attendant never needs the "pull forward" system; they only ever say "here's your order" (OKAY) or "sorry, we can't make that one" (ERROR). The waiting is handled by just... waiting; the outcome is success or failure. No bus-release machinery needed.

This captures the simplified responses: the multi-lane drive-through = full AHB; the single-lane one = AHB-Lite; pull forward to a waiting spot (keep other lanes moving) = SPLIT/RETRY (release the bus to other masters); waiting at the window = HREADY wait states; "here's your order" = OKAY; "sorry, can't make that" = ERROR; no one behind you = no other master. One lane, one car — just wait at the window; success or failure; no pull-forward system needed.

Watch the two outcomes — wait-then-OKAY and a two-cycle ERROR:

AHB-Lite responses: wait-then-OKAY, then a two-cycle ERROR

4 cycles

Figure 2 — the two AHB-Lite outcomes. Transfer 1 (to a slow slave): the slave inserts a wait state (HREADY low, HRESP OKAY in cycle 1), then completes (HREADY high, HRESP OKAY in cycle 2) — delay handled by wait states. Transfer 2 (a failing access): the slave gives the two-cycle ERROR — HRESP ERROR with HREADY low (cycle 3), then HRESP ERROR with HREADY high (cycle 4). Only OKAY and ERROR ever appear; SPLIT/RETRY never do.

The model's lesson: single-lane drive-through — just wait at the window; only "here's your order" or "can't make that." In the waveform, delay is a wait state (HREADY low, OKAY), and failure is the two-cycle ERROR — never SPLIT/RETRY.

4. Real Hardware Perspective

In hardware, the simplified response model means slaves implement only OKAY/ERROR response logic plus HREADY wait-state generation — no SPLIT/RETRY machinery, and no HSPLIT signal — which is a meaningful slave-side simplification.

The removed SPLIT/RETRY logic is the saving: a full-AHB SPLIT-capable slave is complex — it must issue the SPLIT response, remember which master it split (so it can later signal that master), drive the HSPLIT bitmap to the arbiter when ready, and handle the master being re-granted to resume. RETRY is simpler but still adds a response path and master-retry handling. All of this is removed in AHB-Lite: no SPLIT issuance, no master-tracking, no HSPLIT, no RETRY path. So the slave's response logic shrinks to driving OKAY/ERROR. So in hardware, the simplification deletes the SPLIT/RETRY machinery (and HSPLIT) from slaves.

Figure 3 — the two slave outcomes. Left (needs time, succeeds): the slave holds HREADY low for wait states with HRESP = OKAY, then drives HREADY high with HRESP = OKAY to complete. Right (fails): the two-cycle ERROR — HRESP = ERROR with HREADY low, then HRESP = ERROR with HREADY high. Both use only OKAY/ERROR; delay uses wait states, failure uses ERROR. The first ERROR cycle warns the master so it can cancel a pipelined follow-on.

The wait-state mechanism is what remains for delay: the slave drives HREADY low to insert wait states (stretching the data phase) and HREADY high to complete. This is the same wait-state logic full-AHB slaves use for short delays — nothing new; it's just now the only delay mechanism (no SPLIT/RETRY alternative for long delays). So a slow AHB-Lite slave (flash, an off-chip memory controller) simply holds HREADY low for as many cycles as it needs. The master waits (it has nothing else to do — one master). So in hardware, delay is handled entirely by HREADY wait states. (Chapter 12.6 details the slave's HREADY generation, including the HREADYOUT/HREADY relationship in a multi-slave system.)

The two-cycle ERROR is retained unchanged (chapter 7.x / 11.5): the slave drives HRESP = ERROR with HREADY low (first cycle, the warning), then HRESP = ERROR with HREADY high (second cycle, completion). The two cycles let the master cancel any pipelined follow-on transfer before the ERROR completes. So the ERROR response logic is identical to full AHB's — AHB-Lite doesn't simplify ERROR (it's a transfer outcome, needed); it only removes SPLIT/RETRY (bus management, not needed). So in hardware, AHB-Lite slaves implement: HREADY wait-state generation (for delay), OKAY (success), and the standard two-cycle ERROR (failure) — and omit the SPLIT/RETRY machinery and HSPLIT. The result is a simpler slave response unit. So the hardware perspective: the response simplification is a real slave-side logic reduction (no SPLIT/RETRY), with delay handled by the retained, universal wait-state mechanism.

5. System Architecture Perspective

At the system level, the simplified response model reflects the clean separation of timing (HREADY) from outcome (HRESP), simplifies slave IP, and is sufficient precisely because a single master has nothing better to do during a wait.

The timing/outcome orthogonality is the architectural clarity: AHB-Lite's model cleanly separates two concerns. Timing — how long a transfer takes — is governed entirely by HREADY (wait states stretch it; HREADY high completes it). Outcome — whether it succeeded — is governed entirely by HRESP (OKAY or ERROR), sampled when HREADY is high. These are orthogonal: a transfer can be fast or slow (HREADY) and succeed or fail (HRESP) independently. Full AHB's SPLIT/RETRY muddied this (they mixed "needs time" with "release the bus"); AHB-Lite's two-axis model (HREADY for time, HRESP for outcome) is cleaner and easier to reason about and verify. So at the system level, the simplification yields a clean, orthogonal timing-vs-outcome model.

The slave-IP simplification is the practical benefit: AHB-Lite slaves are simpler to design, integrate, and verify because they have a smaller response repertoire (no SPLIT/RETRY). A reusable AHB-Lite slave needs only OKAY/ERROR + wait-state logic — less RTL, fewer corner cases, simpler verification (no SPLIT resumption scenarios, no HSPLIT/arbiter interaction). Across an ecosystem of slave IP (memories, peripherals), this is a real reduction in design and verification cost. So at the system level, simplified responses make AHB-Lite slave IP leaner and easier to get right — contributing to AHB-Lite's attractiveness for building many-slave systems.

The sufficiency argument ties it together: is OKAY/ERROR + wait states enough? Yes — provably, for one master. The only thing SPLIT/RETRY add over wait states is releasing the bus to other masters during a long wait — a throughput optimization that only helps when there are other masters. With one master, there are none, so the optimization gains nothing: the single master would just wait anyway (it has no other bus work to do — it's a single thread). So stalling it with wait states is exactly as good as releasing-and-resuming would be, but simpler. So the simplified model isn't a compromise for single-master systems — it's complete; SPLIT/RETRY would add complexity with zero benefit. So at the system level, the simplified response model is the right and sufficient model for single-master systems: a clean timing/outcome separation, simpler slave IP, and no loss versus the full model (because the only thing dropped — bus-release-to-others — has no value with one master). It's another instance of AHB-Lite removing exactly what's vacuous, leaving a model that's both simpler and complete. So the response simplification, like removed arbitration, is a principled, lossless reduction for the single-master case.

6. Engineering Tradeoffs

The simplified response model embodies the outcome-only, delay-via-wait-states design.

OKAY/ERROR only vs four codes. Two codes (outcome) plus wait states (delay) is simpler and complete for one master, at the cost of no bus-release option. Four codes (adding SPLIT/RETRY) enable multi-master bus-release but add complexity. One master → two codes suffice.
Wait states vs SPLIT/RETRY for delay. Wait states (hold HREADY low) handle delay simply; SPLIT/RETRY handle it by releasing the bus to others. With one master, releasing gains nothing, so wait states are strictly simpler and lossless.
Orthogonal timing/outcome vs conflated. Separating HREADY (timing) from HRESP (outcome) is clean and easy to verify; SPLIT/RETRY conflated delay with bus-management. The orthogonal model is clearer.
Simpler slave IP vs full slave. AHB-Lite slaves omit SPLIT/RETRY machinery (and HSPLIT) — less RTL, fewer corner cases, simpler verification — at no cost for single-master systems.

The throughline: AHB-Lite's response model keeps only OKAY (success) and ERROR (the two-cycle failure), removing SPLIT and RETRY — which exist only to release the bus to other masters, vacuous with one. A slow slave inserts HREADY wait states for delay. The model cleanly separates timing (HREADY) from outcome (HRESP), simplifies slave IP, and is complete for single-master systems (the dropped bus-release optimization has zero value with one master). It's a principled, lossless reduction.

A slow AHB-Lite slave uses wait states — it must NOT need SPLIT/RETRY, and it must still drive a defined HRESP every cycle

Two correctness points about AHB-Lite slave responses. First, a slow slave handles delay only with wait states (HREADY low) — it has no SPLIT/RETRY to fall back on, and it doesn't need them. An AHB-Lite slave that takes many cycles (a slow flash, an external memory) simply holds HREADY low for the entire delay, then drives HREADY high to complete. There's no upper limit imposed by the protocol on wait states (though system-level watchdogs may bound them) — the single master just waits. A slave designer must not assume a SPLIT/RETRY escape hatch exists; in AHB-Lite, wait states are the only delay mechanism. Second, the slave must drive a defined HRESP every data-phase cycle, including during wait states. While inserting wait states (HREADY low), the slave drives HRESP = OKAY (the transfer is proceeding, just not done). It switches to ERROR only if the transfer fails, and then uses the two-cycle ERROR protocol (HRESP = ERROR with HREADY low, then HREADY high) — it cannot signal ERROR in a single cycle, because the master needs the first ERROR cycle as a warning to cancel any pipelined follow-on transfer. A common slave bug is driving HRESP = ERROR with HREADY already high in the same cycle (a one-cycle error) — this violates the protocol; the master may not handle it, and a pipelined follow-on transfer wouldn't be cleanly canceled. So: delay via wait states (HRESP = OKAY while waiting), failure via the two-cycle ERROR, and always a defined HRESP. Getting the two-cycle ERROR timing right is the subtle part — wait states are easy, but the ERROR handshake must follow the HREADY-low-then-high sequence.

7. Industry Example

See the simplified responses in a single-master system.

An MCU's CPU (sole master) accesses flash, SRAM, and peripherals over AHB-Lite.

Fast SRAM read (zero wait, OKAY). The CPU reads SRAM; the SRAM completes in one cycle — HREADY high, HRESP = OKAY, data returned. The fastest case: no wait states, OKAY.
Slow flash read (wait states, then OKAY). The CPU reads flash, which needs (say) 3 cycles. The flash controller holds HREADY low for 2 wait states (HRESP = OKAY throughout — the transfer is proceeding), then drives HREADY high with HRESP = OKAY and the data. The CPU waits the 3 cycles. No SPLIT/RETRY — just wait states. (In a multi-master system, the flash might SPLIT to free the bus for a DMA during those cycles; with one master, there's no DMA to benefit, so wait states are right.)
Access to an unmapped address (two-cycle ERROR). The CPU accesses a gap; the default slave returns the two-cycle ERROR — HRESP = ERROR with HREADY low, then HRESP = ERROR with HREADY high. The CPU faults. (Chapter 11.5.)
Write to a read-only region (two-cycle ERROR). The CPU writes to flash that's read-only; the flash controller returns the two-cycle ERROR. The CPU faults. Failure is always ERROR.
No SPLIT/RETRY anywhere. Across all these, the only responses the CPU ever sees are OKAY and ERROR; delays are always wait states. The bus has no HSPLIT, no SPLIT/RETRY handling. The CPU's response handling is correspondingly simple: wait while HREADY low, then check HRESP for OKAY/ERROR.

The example shows the model end-to-end: fast access (OKAY, no wait), slow access (wait states, then OKAY), and failures (two-cycle ERROR) — covering every case with just OKAY/ERROR + wait states, no SPLIT/RETRY. This is the complete, sufficient response model for a single-master MCU.

8. Common Mistakes

Simplified-responses misconceptions

"Without SPLIT/RETRY, a slow slave can't take extra time." No — it uses wait states (HREADY low), the universal delay mechanism. SPLIT/RETRY only added bus-release-to-others.
"AHB-Lite slaves can't report errors." They can — ERROR (the two-cycle response) is kept. Only SPLIT/RETRY are removed.
"A slave can signal ERROR in one cycle in AHB-Lite." No — ERROR is always the two-cycle response (HREADY low then high), so the master can cancel a pipelined follow-on.
"During wait states the slave drives ERROR or undefined HRESP." No — it drives HRESP = OKAY while waiting (the transfer is proceeding); it switches to ERROR only on failure.
"SPLIT/RETRY would improve AHB-Lite performance." No — they only help by freeing the bus for other masters; with one master, they'd add complexity with zero benefit.
"Removing SPLIT/RETRY limits how long a slave can wait." No — wait states can extend a transfer arbitrarily (subject to system watchdogs); there's no protocol limit forcing SPLIT.

9. Interview Insight

The simplified response model is a focused interview topic — the OKAY/ERROR-only model, the why-SPLIT/RETRY-go reasoning, and the delay-via-wait-states point are the signals.

Figure 4 — a strong answer in one card: HRESP has only OKAY and ERROR (SPLIT/RETRY dropped, as they only release the bus to others); a slave needing time uses wait states (HREADY low), so delay is orthogonal to the response; ERROR is the standard two-cycle response. The senior point: with one master there's no benefit to releasing the bus, so wait states plus OKAY/ERROR cover every case.

The answer that lands gives the model and the reasoning: "AHB-Lite's response model keeps only two HRESP codes: OKAY for success and ERROR for failure — the standard two-cycle ERROR. It drops SPLIT and RETRY. The reason is that SPLIT and RETRY aren't really about the transfer's outcome — they're a multi-master bus-management mechanism: they let a slow slave release the bus so other masters can use it during a long wait, and resume or retry later. With a single master, there's no other master to hand the bus to, so releasing it gains nothing — the single master would just wait anyway. So SPLIT/RETRY are pointless and removed. How does a slow slave take more time, then? With wait states — it holds HREADY low for as many cycles as it needs, driving HRESP = OKAY meanwhile, then drives HREADY high to complete. The key principle is that delay and outcome are orthogonal: HREADY handles timing, HRESP handles outcome. This isn't a compromise — for one master, OKAY/ERROR plus wait states is complete, because the only thing SPLIT/RETRY added was bus-release-to-others, which has no value with one master. The slave is simpler too: no SPLIT/RETRY machinery, no HSPLIT." The OKAY/ERROR model, the bus-release reasoning, and the orthogonal-delay point are the senior signals.

🔍 The discriminator: SPLIT/RETRY are bus-management, not outcomes — wait states cover delay losslessly with one master

The discriminator on simplified responses is whether you recognize that SPLIT/RETRY are bus-management mechanisms, not transfer outcomes — and that removing them is lossless for one master because wait states cover delay. A weak answer says "AHB-Lite only has OKAY and ERROR." A solid answer adds that SPLIT/RETRY are removed and a slow slave uses wait states. But the senior answer explains what SPLIT/RETRY actually were: a multi-master optimization to release the shared bus to other masters during a long wait (SPLIT remembers the master and re-grants via the arbiter; RETRY has the master retry) — fundamentally about bus throughput across masters, not about whether a transfer succeeded. So they're orthogonal to outcome. The senior insight is why their removal is lossless: the only benefit SPLIT/RETRY provide is freeing the bus for other masters during a wait — and with one master, there are none, so the single master would just wait regardless; stalling it with wait states is exactly as good, and simpler. So OKAY/ERROR + wait states is complete, not a compromise. The clean framing is the orthogonality: HREADY governs timing (how long), HRESP governs outcome (success/fail) — two independent axes — whereas SPLIT/RETRY conflated 'I need time' with 'let others use the bus.' The flourish is the slave-design correctness: during wait states the slave drives HRESP = OKAY (not undefined), and failure uses the two-cycle ERROR (never one-cycle), so the master can cancel a pipelined follow-on. A candidate who frames SPLIT/RETRY as bus-management, explains the lossless-for-one-master removal, and notes the timing/outcome orthogonality demonstrates they understand why the response model simplifies, not just that it does.

10. Practice Challenge

Reason from the simplified responses.

The model. State the AHB-Lite response codes and how delay is handled.
Why SPLIT/RETRY go. Explain what SPLIT/RETRY did and why they're vacuous with one master.
Read the waveform. From Figure 2, identify the wait-then-OKAY and the two-cycle ERROR, and what HRESP is during the wait state.
Lossless. Explain why removing SPLIT/RETRY costs no performance for a single master.
Orthogonality. Explain the timing/outcome orthogonality (HREADY vs HRESP) and why it's cleaner.

11. Key Takeaways

AHB-Lite's HRESP has only OKAY and ERROR — SPLIT and RETRY are removed (they exist only to release the bus to other masters, vacuous with one master).
A slow slave inserts HREADY wait states for delay — the universal AHB delay mechanism — driving HRESP = OKAY while waiting, then HREADY high to complete.
ERROR is the standard two-cycle response — HRESP = ERROR with HREADY low, then HREADY high — so the master can cancel a pipelined follow-on; never a one-cycle ERROR.
Delay and outcome are orthogonal — HREADY governs timing (how long), HRESP governs outcome (success/fail); the two axes are independent. SPLIT/RETRY had conflated them.
The removal is lossless for one master — SPLIT/RETRY's only benefit was bus-release-to-others, worth nothing with one master; wait states give identical timing with less logic.
Slaves are simpler — no SPLIT/RETRY machinery, no HSPLIT, no master-tracking — easier to design and verify.

12. What Comes Next

You now understand AHB-Lite's simplified response model — OKAY/ERROR with wait states for delay. The next chapters ground AHB-Lite in real designs and slave construction:

Typical Microcontroller Use (next) — AHB-Lite in a real microcontroller bus fabric.
AHB-Lite Slave Design — how to build a correct AHB-Lite slave (HSEL/HTRANS qualification, address-phase capture, HREADY generation, the response logic).
AHB-Lite vs Full AHB — a precise tabulation of what's kept and dropped.

To revisit the responses this builds on, see The ERROR Response and Slave-Inserted Wait States; for the removed arbitration, see Removed Arbitration.