AMBA AHB · Module 7

How the Master Reacts

The AHB master's response-handling state machine — how it reacts to OKAY (proceed), ERROR (cancel next, fault), RETRY (re-issue), and SPLIT (park for re-grant) — and the common cancel-the-next-transfer step every non-OKAY response shares.

Chapters 7.1–7.6 covered each response from the subordinate's side — what OKAY, ERROR, RETRY, and SPLIT mean and how they're signaled. This chapter takes the master's side: how it reacts to each response. The master is, in effect, a small state machine: it samples the response on the HREADY-high cycle and branches — OKAY → proceed, ERROR → cancel the next transfer and fault, RETRY → cancel and re-issue, SPLIT → cancel and park for re-grant. A unifying theme emerges: every non-OKAY response shares a common first step — cancel the already-pipelined next transfer (drive HTRANS to IDLE in the warning cycle, chapter 7.6) — before diverging into response-specific handling. Understanding the master's reaction completes the response picture from both sides.

1. What Is It?

The master's response handling is a state machine that samples HRESP on the HREADY-high cycle (chapter 7.5) and branches on the value into response-specific behavior:

OKAY → consume the result (read data / write done) and proceed to the next transfer. The common fast path.
ERROR → cancel the next transfer, then raise a fault / abort. (Read data invalid, write state uncertain.)
RETRY → cancel the next transfer, then re-arbitrate and re-issue the same transfer; repeat until OKAY. (Full AHB only.)
SPLIT → cancel the next transfer, then wait parked (masked) and re-issue when re-granted via HSPLIT. (Full AHB only.)

Figure 1 — the master's response-handling state machine. From NORMAL, it samples the response on the HREADY-high cycle and branches: OKAY loops back to NORMAL (consume, proceed); ERROR goes to fault handling (cancel next, then exception/abort); RETRY goes to re-issue (re-arbitrate, re-present the same transfer); SPLIT goes to parked (wait to be re-granted via HSPLIT). RETRY and SPLIT loop back to NORMAL once the re-issued transfer completes OKAY.

The common thread across all non-OKAY responses is the first step: cancel the next transfer. Because the pipeline already issued the next transfer's address phase (chapter 7.6), every non-OKAY response begins with the master driving that next transfer's HTRANS to IDLE during the warning cycle. Then the handling diverges: ERROR faults, RETRY re-issues, SPLIT parks. So the master's reaction has a shared prefix (cancel the next transfer) and a response-specific suffix (fault / re-issue / park). OKAY alone needs no cancellation — it just proceeds.

2. Why Does It Exist?

The master's response-handling state machine exists because each response demands a different action, and the master is the component responsible for taking that action — the subordinate only signals the outcome; the master must respond to it.

Recall that responses report outcomes (chapter 7.2's "report not fix"): the subordinate says what happened (OKAY/ERROR/RETRY/SPLIT), but it's the master that must do something about it. And the right action differs per response: success means proceed, failure means handle the fault, RETRY means try again, SPLIT means wait to be called back. So the master needs logic that distinguishes the responses and takes the appropriate action for each — which is exactly a state machine that branches on the response value. The handler exists because responses are the subordinate's half of a two-part contract (signal + react), and the master's response handling is the react half.

The reason every non-OKAY response shares the cancel-the-next-transfer first step is the pipeline (chapter 7.6): whenever something goes other-than-normally, the already-issued next transfer must be reconsidered — for ERROR it should usually be cancelled (don't proceed after a failure), for RETRY/SPLIT it must be cancelled because the current transfer didn't complete and the master's flow is interrupted. So the pipeline forces a common cancellation step on any non-OKAY response: the next transfer, issued on the assumption the current one would complete normally, must be stopped when it doesn't. This shared step exists because the pipeline always has a next transfer in flight, and any non-normal outcome means that next transfer shouldn't blindly proceed.

The reason OKAY needs no special handling (just proceed) is that OKAY is the normal flow the pipeline assumed — the next transfer was issued correctly, the result is valid, nothing is interrupted. So OKAY requires no cancellation and no branch; the master just consumes the result and continues. This is why OKAY is the silent fast path (chapter 7.1): the master's handler does nothing special for it, which keeps the common case efficient. The handler's complexity is entirely in the non-OKAY branches; OKAY flows straight through. So the master's response handling exists to handle the exceptions — OKAY is the default no-op, and the state machine's real work is the ERROR/RETRY/SPLIT branches.

3. Mental Model

Model the master's response handling as a driver reacting to a traffic signal at an intersection — green: go (OKAY); but any non-green means first stop the car you were about to send through (cancel the next transfer), then act on the specific signal.

You're driving (the master), approaching intersections in sequence (the pipeline — you're already rolling toward the next one). A green light (OKAY) means just proceed — no special action, you flow through. But any non-green requires you to first stop — hold back the move you were about to make into the next intersection (cancel the already-committed next transfer) — and then respond to the specific signal: a red light (ERROR) means stop and deal with it (you can't proceed — handle the situation); a "wait, try again" flagger (RETRY) means circle back and approach again; a "we'll wave you through when ready" attendant (SPLIT) means pull over and wait to be called. The common first move for anything non-green is to not blindly roll into the next intersection — then you handle the specific signal.

This captures the handler: green = go = OKAY proceed (no special action); any non-green = first stop the next move = cancel the pipelined next transfer; then the specific signal = ERROR/RETRY/SPLIT-specific handling. The shared "stop the next move" step exists because you're always already rolling toward the next intersection (the pipeline), so any non-normal signal requires holding that back first.

Watch the master's common cancel-then-react pattern:

The master's cancel-then-react pattern for non-OKAY responses

4 cycles

Figure 2 — the master's cancel-then-react pattern (shown for a non-OKAY response). On the warning cycle (HRESP non-OKAY, HREADY low), the master drives HTRANS to IDLE — cancelling the next transfer (the shared first step). On the completion cycle (HREADY high), it commits to the response and takes the response-specific action (fault for ERROR, re-issue for RETRY, park for SPLIT). OKAY would skip this entirely — proceeding straight through.

The model's lesson: for any non-OKAY response, first stop the next move (cancel the next transfer), then act on the specific signal. In the waveform, the master drives HTRANS to IDLE on the warning cycle (the shared step) and takes the response-specific action on completion. OKAY alone flows straight through, no cancellation.

4. Real Hardware Perspective

In hardware, the master's response handling is control logic (a state machine) that, on each transfer's completion, dispatches on HRESP — with the OKAY path being the simple datapath flow and the non-OKAY paths being the exception-handling states.

The OKAY path is the master's normal datapath: capture read data (or note write completion) on the HREADY-high cycle, and advance to issue the next transfer. There's no branch — it's the straight-through flow. So in hardware, OKAY handling is just the master's ordinary operation; the response-handling state machine only diverges from this on a non-OKAY value. This is why OKAY is "free" — it's the path the master already follows.

The ERROR path does two hardware things: in the warning cycle, drive the next transfer's HTRANS to IDLE (cancel it, chapter 7.6); on completion, not use the read data (it's invalid) and signal the master's error mechanism — for a processor, this typically becomes a bus-fault exception to the CPU; for a DMA engine, it might set an error status and stop. So the ERROR path's hardware connects to the master's broader error/exception machinery. The handling is "report up": the master surfaces the bus error to its higher-level logic (CPU exception, DMA error flag), which implements the recovery policy (chapter 7.2). The bus-level master just cancels the next transfer and raises the error; software/higher logic decides what to do.

The RETRY path re-issues: cancel the next transfer, then re-arbitrate (request the bus) and re-present the same transfer (the master retained its address/control/data, chapter 7.3). In hardware, this means the master keeps the transfer's information and loops back to re-issue it — a re-issue state that returns to normal once the transfer finally gets OKAY. The SPLIT path is similar but parks: cancel the next transfer, then wait (the arbiter has masked the master) until re-granted via HSPLIT (chapter 7.4), then re-issue. So RETRY's hardware actively re-issues (polls), while SPLIT's hardware waits to be re-granted (no polling). Both retain the transfer to re-present it.

Figure 3 — one handler, four branches. OKAY: consume the result and proceed (the common case, no special handling). ERROR: cancel the next transfer (HTRANS→IDLE), then raise a fault/abort — read data invalid, write uncertain. RETRY: cancel next, re-arbitrate, and re-issue the same transfer until OKAY (full AHB; the master polls). SPLIT: cancel next, wait parked, re-issue when re-granted via HSPLIT (full AHB; no polling). Every non-OKAY response shares the cancel-the-next-transfer first step.

A hardware note on which responses a master must handle: a master only needs handling logic for the responses its bus can produce. In AHB-Lite/AHB5, only OKAY and ERROR exist, so the master needs only those two paths — much simpler (chapter 7.8). In full AHB, the master must also handle RETRY and SPLIT (re-issue and park logic, plus re-arbitration). So a full-AHB master is significantly more complex than an AHB-Lite master, precisely because of the RETRY/SPLIT handling. This is part of why AHB-Lite masters are simpler and more common — they handle only the two universal responses. A master designed for AHB-Lite that's later placed in a full-AHB system would need RETRY/SPLIT handling added.

5. System Architecture Perspective

At the system level, the master's response handling is where the bus's outcomes connect to the system's behavior — OKAY drives normal data flow, ERROR feeds the fault/exception architecture, and RETRY/SPLIT drive arbitration interactions — making the master the bridge between bus responses and system-level policy.

The ERROR → exception path is the most system-significant. When a master (especially a processor) receives ERROR, it typically raises a bus-fault exception, entering the system's fault-handling architecture: the CPU's exception handler runs, logs the fault, and decides recovery (terminate the task, retry at a higher level, report, etc.). So the master's ERROR handling is the entry point from bus-level failure to system-level fault handling (chapter 7.2). This connection — bus ERROR becomes CPU exception — is how hardware faults, illegal accesses, and protection violations surface to software. The master is the translator: it turns a bus response into a system event. This is a critical architectural role: the master's response handling is where bus errors become actionable at the system level.

The OKAY path drives throughput: since OKAY is the common case and flows straight through, the master's normal data flow (and thus system throughput) is determined by the OKAY path's efficiency — how fast the master streams OKAY transfers (with their wait states, Module 6). So the master's OKAY handling, being a no-op beyond consuming data, keeps the throughput path clean. The system's performance lives in the OKAY path; the master's job there is to not get in the way (consume and proceed efficiently). This is the performance-vs-robustness split again (chapter 7.1): OKAY handling for throughput, ERROR handling for robustness.

The RETRY/SPLIT paths drive arbitration behavior (full AHB): a master that gets RETRY re-arbitrates (competing for the bus again), and a master that gets SPLIT is masked and later un-masked by the arbiter. So in a multi-master full-AHB system, the masters' RETRY/SPLIT handling interacts with the arbiter to determine bus sharing under slow subordinates — the system's multi-master throughput emerges from these interactions. This coupling (master handling ↔ arbiter) is part of full AHB's complexity, and its removal (AHB-Lite drops RETRY/SPLIT) is part of why AHB-Lite masters and arbitration are simpler. So the master's response handling, especially RETRY/SPLIT, is tied to the system's arbitration architecture.

So the master's response handling connects the bus to the system across all responses: OKAY to data flow/throughput, ERROR to fault/exception handling, and RETRY/SPLIT to arbitration. The master is the component that turns bus-level outcomes into system-level behavior — which is why its response handling is a key part of the overall architecture, not just a bus-protocol detail.

6. Engineering Tradeoffs

The master's response handling reflects the cancel-then-branch, exception-on-non-OKAY design.

Branch-on-response vs uniform handling. A state machine that branches per response handles each correctly but adds per-response logic. Uniform handling would be simpler but couldn't take the right action per response. The master must branch — each response demands different action — with OKAY kept as the no-branch fast path.
Cancel-next-first vs response-specific-only. Sharing the cancel-the-next-transfer step across all non-OKAY responses is uniform and safe (the pipelined next transfer is always handled) at the cost of the master always reacting in the warning cycle. Handling cancellation per-response separately would duplicate logic. The shared cancel step is cleaner.
Report-up (exception) vs handle-in-master. The master surfacing ERROR as an exception (to CPU/software) keeps recovery policy flexible (chapter 7.2) at the cost that the master alone can't recover. Handling recovery entirely in the master would be rigid. AHB masters report up — policy lives in software.
Full handling (OKAY/ERROR/RETRY/SPLIT) vs minimal (OKAY/ERROR). A full-AHB master handles all four (complex: re-issue, park, re-arbitrate); an AHB-Lite master handles only two (simple). The trade is multi-master capability vs simplicity — and most systems chose AHB-Lite's simplicity (chapter 7.8), handling multi-master at the interconnect level.

The throughline: the master's response handling samples on HREADY high and branches — OKAY proceeds (fast path), and every non-OKAY first cancels the next transfer then takes its specific action (ERROR faults, RETRY re-issues, SPLIT parks). The design keeps the common case (OKAY) free, shares the cancellation step for safety, reports errors up for policy flexibility, and scales from minimal (AHB-Lite: OKAY/ERROR) to full (RETRY/SPLIT). It's the master half of the response contract — well-factored into a fast path and exception branches.

Don't use read data or assume a write happened on a non-OKAY response

A critical correctness rule in the master's handling: on any non-OKAY response, do not use the read data and do not assume the write took effect. For ERROR, the read data is invalid and the write state is uncertain (chapter 7.2) — using the data or trusting the write would propagate corruption. For RETRY and SPLIT, the transfer did not complete at all — it was cancelled and must be re-issued — so there is no valid result yet; the data from a RETRY/SPLIT 'attempt' is meaningless. So the master must gate its result-consumption on OKAY specifically: only on OKAY does it consume read data or consider a write done. On ERROR, discard/flag; on RETRY/SPLIT, the transfer is pending re-issue, so there's nothing to consume. A master that consumed data regardless of the response — treating a non-OKAY completion like an OKAY one — would use garbage (ERROR) or non-existent (RETRY/SPLIT) results. Consume results only on OKAY; branch to handling on everything else.

7. Industry Example

Trace a processor master's response handling across a workload.

A processor issues a stream of transfers and handles whatever responses come back.

OKAY stream — normal flow. Most transfers return OKAY: the processor consumes read data (or notes write completion) and proceeds to the next transfer, streaming through. This is the throughput path — no special handling, just data flow. The vast majority of the workload is here.
An ERROR — fault handling. A transfer hits an unmapped address; the default subordinate returns the two-cycle ERROR. The processor, in the warning cycle, cancels the next transfer (HTRANS→IDLE); on completion, it does not use the read data, and raises a bus-fault exception. The CPU's exception handler runs — logs the bad address, terminates the offending task. The ERROR became a system-level fault. The processor's handling bridged bus to software.
A RETRY (full AHB) — re-issue. In a full-AHB system, a busy subordinate returns RETRY. The processor cancels the next transfer, re-arbitrates, and re-issues the same transfer. It keeps re-issuing until the subordinate returns OKAY, then consumes the result and proceeds. The processor polled, as RETRY requires.
A SPLIT (full AHB) — park. A slow subordinate returns SPLIT. The processor cancels the next transfer and is parked by the arbiter (masked) — it does nothing on the bus until the arbiter re-grants it (on HSPLIT). When re-granted, it re-issues and completes OKAY. The processor waited efficiently, not polling.
The unified handler. Throughout, the processor used one handler: sample the response on HREADY high, branch. OKAY flowed through; non-OKAY responses first cancelled the next transfer, then took their specific action (fault / re-issue / park). And it consumed results only on OKAY — never using data from an errored or cancelled transfer.
AHB-Lite simplification. Had this been an AHB-Lite system, the processor would only ever see OKAY and ERROR — so its handler would need just those two paths (proceed / fault), with no RETRY/SPLIT logic. Simpler master, which is the common modern case (chapter 7.8).

The example shows the master's response handling as the unified branch-on-response machine: OKAY drives the throughput path, ERROR feeds the exception architecture, and RETRY/SPLIT (full AHB) drive re-issue and parking. The shared cancel-the-next-transfer step and the consume-only-on-OKAY rule keep it correct across all responses.

8. Common Mistakes

Master response-handling mistakes

"The master consumes read data regardless of the response." No — consume data only on OKAY. On ERROR the data is invalid; on RETRY/SPLIT the transfer didn't complete (nothing to consume).
"Only ERROR requires cancelling the next transfer." No — every non-OKAY response (ERROR/RETRY/SPLIT) first cancels the already-pipelined next transfer (HTRANS→IDLE in the warning cycle). OKAY alone doesn't.
"The master recovers from an ERROR itself." Typically it reports up — raises a CPU bus-fault exception; recovery policy lives in software (report not fix, chapter 7.2).
"RETRY and SPLIT handling are the same." No — RETRY re-issues (the master polls); SPLIT parks (the master waits to be re-granted, no polling). Different master behavior.
"Every AHB master handles four responses." Only full-AHB masters handle OKAY/ERROR/RETRY/SPLIT. AHB-Lite/AHB5 masters handle only OKAY and ERROR (chapter 7.8).
"OKAY needs handling logic." OKAY is the straight-through datapath (consume, proceed) — no branch. The handler's logic is all in the non-OKAY exception branches.

9. Interview Insight

How the master reacts is a synthesizing interview question — it tests whether you can tie all the responses together from the master's side.

Figure 4 — a strong answer in one card: the master samples the response on the HREADY-high cycle and branches — OKAY: consume & proceed; ERROR: cancel next, then fault/abort; RETRY: cancel next, re-issue the same transfer; SPLIT: cancel next, wait parked for re-grant. Every non-OKAY response first cancels the already-pipelined next transfer (HTRANS→IDLE). The senior point: OKAY is the silent fast path, the others are exception branches, and RETRY/SPLIT are full-AHB only.

The answer that lands organizes the handling as a branch-on-response machine with a shared step: "The master samples the response on the HREADY-high cycle and branches. OKAY is the fast path — it just consumes the read data or notes the write done and proceeds. Every non-OKAY response first does the same thing: cancel the already-pipelined next transfer by driving HTRANS to IDLE in the warning cycle. Then they diverge — ERROR: don't use the data, raise a fault (typically a CPU bus-fault exception, recovery is software policy); RETRY: re-arbitrate and re-issue the same transfer, polling until OKAY; SPLIT: park (the arbiter masks the master) and re-issue when re-granted via HSPLIT. Crucially, the master consumes results only on OKAY — never on a non-OKAY response. And RETRY/SPLIT only exist in full AHB; an AHB-Lite master handles just OKAY and ERROR." The shared cancel step, the consume-only-on-OKAY rule, and the AHB-Lite simplification are the senior signals.

🔍 The discriminator: the shared cancel-next step and consume-only-on-OKAY

Two insights distinguish a strong answer on master response handling. First, the shared cancel-the-next-transfer step: a junior answer lists per-response actions separately; a senior answer notices that every non-OKAY response begins with the same step — cancel the already-pipelined next transfer (drive HTRANS to IDLE in the warning cycle) — because the pipeline always has a next transfer in flight that mustn't blindly proceed when something goes wrong. This shows you understand the pipeline's role in response handling, not just the per-response actions. Second, consume-only-on-OKAY: a senior answer stresses that the master must gate result-consumption on OKAY specifically — never using read data on ERROR (invalid) or RETRY/SPLIT (transfer didn't complete) — a correctness rule that's easy to miss. The flourish is the architectural framing: OKAY is the silent throughput path, ERROR is the bridge to the system's fault/exception architecture, RETRY/SPLIT drive arbitration interactions (full AHB only), and AHB-Lite masters need only the OKAY/ERROR paths. A candidate who frames the master as a branch-on-response machine with a shared cancellation prefix and a strict consume-only-on-OKAY rule — and connects each branch to its system role — demonstrates they've synthesized the whole response module from the master's perspective. That synthesis is the senior signal.

10. Practice Challenge

Reason from the master's response-handling machine.

Map the branches. State the master's action for each of OKAY, ERROR, RETRY, SPLIT.
The shared step. Identify what every non-OKAY response does first and why.
Read the waveform. From Figure 2, identify the warning-cycle action and the completion-cycle action.
The consumption rule. Explain why the master must consume results only on OKAY.
System bridge. Explain how the master connects ERROR to the system's fault handling.

11. Key Takeaways

The master samples HRESP on the HREADY-high cycle and branches: OKAY → consume & proceed; ERROR → cancel next, fault; RETRY → cancel next, re-issue same; SPLIT → cancel next, park for re-grant.
Every non-OKAY response shares a first step — cancel the already-pipelined next transfer (drive HTRANS to IDLE in the warning cycle) — then diverges. OKAY alone proceeds without cancellation.
Consume results only on OKAY — never use read data on ERROR (invalid) or RETRY/SPLIT (transfer didn't complete).
ERROR is reported up — the master raises a fault (typically a CPU bus-fault exception); recovery policy lives in software.
RETRY re-issues (polls); SPLIT parks (waits for re-grant via HSPLIT) — both retain the transfer to re-present it; only full-AHB masters need this logic.
The master bridges bus responses to system behavior — OKAY to throughput, ERROR to fault/exception handling, RETRY/SPLIT to arbitration. AHB-Lite masters need only OKAY/ERROR.

12. What Comes Next

You now understand response handling from both sides. The next chapter covers the simplification most modern systems use:

7.8 — AHB-Lite Response Simplification (coming next) — how AHB-Lite reduces responses to just OKAY and ERROR, dropping RETRY/SPLIT, and why that's the common modern case.
7.9 — Debugging Bad Responses (coming soon) — diagnosing unexpected ERROR/RETRY/SPLIT from a waveform.

To revisit the responses, see OKAY Response, ERROR Response, RETRY Response, and SPLIT Response. For the two-cycle handshake the master reacts within, see The Two-Cycle ERROR Response. For the broader protocol map, see the AMBA family overview.