Response Timing

Chapters 7.1–7.4 covered what each response means — OKAY, ERROR, and the legacy RETRY/SPLIT. This chapter ties them together with a single timing rule: when is HRESP sampled, and how does it relate to HREADY? The answer unifies everything: HRESP is qualified by HREADY — the transfer's committed outcome is the HRESP value present on the cycle where HREADY is high (the completing cycle). That one rule covers the single-cycle OKAY and the mandatory two-cycle ERROR/RETRY/SPLIT alike. A corollary follows: a subordinate cannot signal a non-OKAY response in a single cycle — during a simple wait HRESP must be OKAY, so the two-cycle handshake is precisely how the bus distinguishes a plain wait from a real error.

1. What Is It?

Response timing is the rule for when HRESP is meaningful: HRESP is read together with HREADY, and the transfer's committed outcome is the HRESP value on the cycle where HREADY is high — the completing cycle.

The rule has two halves:

• On the HREADY-high (completing) cycle, HRESP carries the committed outcome: OKAY means success, ERROR/RETRY/SPLIT mean that result. This is the value the manager acts on.
• While HREADY is low, HRESP is not yet the final outcome: for a simple wait it stays OKAY; for a two-cycle ERROR/RETRY/SPLIT, the low cycle is the warning (the response value appears, but the transfer isn't complete yet).

So the rule unifies all responses under one timing principle: always sample HRESP together with HREADY, and the response that counts is the one present when HREADY is high. For single-cycle OKAY, that's the single completing cycle. For two-cycle responses, the response is present across both cycles, but the transfer completes (and the outcome commits) on the second cycle, when HREADY goes high. The first (HREADY-low) cycle of a two-cycle response is the warning that gives the manager its reaction window (chapter 7.6). One rule, every response.

2. Why Does It Exist?

This timing rule exists because HRESP, like all data-phase signals, is only meaningful in relation to HREADY — the signal that says when the transfer actually completes. Without qualifying HRESP by HREADY, the manager couldn't tell a committed outcome from a transient value during a wait.

Recall that HREADY paces the data phase (Module 6): a transfer's data phase can span multiple cycles (waits), and it completes only on the HREADY-high cycle. HRESP lives in that same data phase, so its meaning is tied to the same completion: the response commits when the transfer completes, i.e., on HREADY high. If the manager read HRESP on a wait cycle (HREADY low) and treated it as final, it would be acting before the transfer completed — exactly the same error as sampling read data during a wait (chapter 6.7). So the rule exists to anchor HRESP's meaning to the actual completion point: HRESP counts when HREADY is high. The response and the completion are read together because the response is about the completion.

The reason non-OKAY responses are two-cycle (and OKAY single-cycle) is to make the warning unambiguous given this timing rule. Because the committed outcome is on the HREADY-high cycle, a subordinate that wants to signal ERROR/RETRY/SPLIT needs a way to warn the manager before that completing cycle — so the manager can react (chapter 7.6). The two-cycle form provides it: the first cycle (HREADY low) shows the non-OKAY value as a warning, and the second (HREADY high) commits it. So the two-cycle structure exists because of the timing rule — it's how a subordinate gives the manager a reaction cycle within the "outcome commits on HREADY high" framework. The single-cycle OKAY needs no warning (success requires no reaction), so it commits immediately.

The corollary — a non-OKAY response can never be single-cycle, and HRESP must be OKAY during a simple wait — exists to keep the distinction between "waiting" and "erroring" clean. If a subordinate could flash ERROR for a single cycle, the manager couldn't distinguish it from a wait, and there'd be no reaction window. By requiring the two-cycle handshake for non-OKAY (and OKAY during simple waits), the protocol makes the two situations unambiguous: HRESP=OKAY with HREADY low is just a wait; a non-OKAY HRESP is always the start of a defined two-cycle sequence. So the rule exists to cleanly separate a plain wait from a real error — the two-cycle handshake is that separation. This is why a subordinate must hold HRESP=OKAY during ordinary wait states.

3. Mental Model

Model response timing as a referee's call that only counts when the whistle blows — during play, gestures are just signals; the official result is what's signaled at the whistle.

In a game (the transfer), the referee (subordinate) makes calls (HRESP). But a call only becomes official when the whistle blows (HREADY high — the completing cycle). During play (HREADY low — wait cycles), the referee might raise an arm to signal "a foul is coming" (the two-cycle warning), but nothing is official yet. The official result is whatever the referee signals at the whistle. So players (the manager) watch the whistle: a raised arm during play is a heads-up (react), but the call that counts is the one at the whistle. And the referee can't make an official call without the whistle — a foul is signaled as "arm up during play, then confirmed at the whistle" (two cycles), never as an instantaneous official call mid-play.

This captures response timing: the whistle = HREADY high (the committing cycle); gestures during play = HRESP while HREADY is low (warning, not final); the official result at the whistle = the committed HRESP outcome on HREADY high; can't make an official call without the whistle = a non-OKAY response is never single-cycle (it needs the warning-then-whistle two-cycle form). The manager, like the players, watches the whistle.

Watch HRESP qualified by HREADY through a wait and a completion:

The model's lesson: the response counts at the whistle — act on HRESP only when HREADY is high. In the waveform, the OKAY during the wait (T1) is not the committed outcome; the OKAY on the completing cycle (T2, HREADY high) is. Whatever HRESP shows, the manager trusts it only on the HREADY-high cycle.

4. Real Hardware Perspective

In hardware, this rule means the manager qualifies its HRESP capture with HREADY — it latches/acts on HRESP only on the HREADY-high cycle — exactly parallel to how it captures read data (chapter 6.3).

The manager's response-handling logic samples HRESP gated by HREADY: on the cycle HREADY is high, it captures HRESP and routes to the appropriate handler (OKAY → proceed; ERROR → fault; RETRY/SPLIT → re-issue/park). On HREADY-low cycles, it does not commit to the response — though for two-cycle responses it uses the warning cycle to prepare its reaction (chapter 7.6). So in hardware, HRESP is captured on HREADY high, just like HRDATA — both are data-phase outputs qualified by the same completion signal. This is the same gating discipline as all data-phase handling: act on HREADY high. A manager that captured HRESP without qualifying it by HREADY would be the response-side analog of the sample-during-wait bug (chapter 6.7).

The two-cycle generation on the subordinate side is the complement: to signal a non-OKAY response, the subordinate drives the response value with HREADY low for one cycle (warning), then with HREADY high for one cycle (completion). In hardware this is the small response state machine (chapter 7.2): it cannot assert a non-OKAY response in a single HREADY-high cycle — the protocol requires the preceding HREADY-low warning cycle. So the subordinate's response logic is built to produce the two-cycle sequence for ERROR/RETRY/SPLIT, and a single HREADY-high cycle for OKAY. This asymmetry (OKAY single, others double) is baked into the subordinate's response generation.

The requirement that HRESP=OKAY during simple waits is a hardware rule the subordinate must honor: while it is merely inserting wait states (HREADY low) without an error, it must drive HRESP=OKAY. It switches HRESP to a non-OKAY value only as part of the defined two-cycle sequence. So a well-behaved subordinate's HRESP is OKAY during ordinary waits and goes non-OKAY only in the two-cycle warning-then-complete pattern. This is what keeps "waiting" and "erroring" distinguishable in hardware: OKAY-during-wait is normal; a non-OKAY value always means a two-cycle response is in progress. A subordinate that flashed a non-OKAY HRESP during a simple wait would violate the protocol and confuse the manager.

A hardware note tying it to the responding subordinate: HRESP, like HREADY and HRDATA, comes from the data-phase subordinate, aggregated by the interconnect on the registered data-phase select (chapter 6.6). So the response timing is consistent with all data-phase signals — HRESP, HREADY, and HRDATA are all from the same responding subordinate for the same transfer, sampled together on the completing cycle. This consistency is why "sample everything on HREADY high from the responding subordinate" is the unified data-phase rule: the response, the readiness, and the data all align on that cycle.

5. System Architecture Perspective

At the system level, this timing rule is what makes response handling uniform and robust — every response is handled by the same "act on HREADY high" discipline — and the two-cycle requirement is what guarantees the manager always has a reaction window for failures.

The uniformity is a system simplification: because every response (OKAY single-cycle, ERROR/RETRY/SPLIT two-cycle) is committed on the HREADY-high cycle, the manager's response handler uses one consistent rule — sample HRESP (and HRDATA) when HREADY is high, then dispatch on the value. There is no per-response-type timing special-casing for when to sample; only the dispatch (what to do) differs by value. So the manager's response logic is structurally simple: one sampling rule, a switch on the response value. This uniformity is a direct benefit of the single timing rule — it keeps response handling clean across all response types.

The guaranteed reaction window is the robustness benefit: because non-OKAY responses are required to be two-cycle (warning then complete), the manager is guaranteed a cycle to react before any failure commits. This is what makes correct failure handling possible in the pipeline (chapter 7.6) — the manager can always cancel the pipelined next transfer or prepare its fault handling during the warning cycle. So the two-cycle requirement isn't just a timing detail; it's a guarantee the architecture relies on for clean error/retry/split handling. Without it (if errors could commit in a single cycle), the pipelined next transfer could proceed before the manager reacted. The system depends on the reaction window the timing rule provides.

The wait-versus-error distinction the rule enforces is architecturally important for correctness: by requiring HRESP=OKAY during simple waits and a two-cycle sequence for non-OKAY, the protocol guarantees the manager can always tell a plain delay from a real failure. So a slow-but-fine transfer (waits, OKAY) and a failing transfer (two-cycle ERROR) are never confused — a critical property, since the manager's actions differ completely (keep waiting vs handle the failure). This unambiguous distinction, enforced by the timing rule, is what lets managers handle the full range of subordinate behaviors correctly. It's the same theme as the OKAY chapter's orthogonality (timing vs outcome), now made precise in timing: waits are OKAY-with-HREADY-low; failures are non-OKAY two-cycle sequences.

So the response-timing rule delivers three system properties: uniform handling (one sampling rule), a guaranteed reaction window (two-cycle non-OKAY), and an unambiguous wait-vs-error distinction (OKAY-during-wait + two-cycle non-OKAY). These are what make AHB's response handling both simple and robust across every response type.

6. Engineering Tradeoffs

The response-timing rule reflects AHB's qualify-by-HREADY, two-cycle-non-OKAY design.

• Qualify HRESP by HREADY vs free-standing HRESP. Tying HRESP's meaning to HREADY (commit on HREADY high) gives one uniform sampling rule and anchors the response to actual completion, at the cost that the manager must always pair the two signals. A free-standing HRESP would be simpler to read in isolation but couldn't distinguish committed from transient values. AHB qualifies by HREADY — correctness and uniformity.
• Two-cycle non-OKAY vs single-cycle. Requiring non-OKAY responses to be two-cycle guarantees a reaction window (clean pipeline handling) at the cost of one extra cycle on failures. Single-cycle non-OKAY would be faster but leave no reaction window. AHB requires two-cycle for non-OKAY — the reaction window is essential; the cost falls only on rare failures.
• Single-cycle OKAY vs uniform two-cycle. Keeping OKAY single-cycle makes the common (success) case fast, at the cost of asymmetry (OKAY single, others double). Making all responses two-cycle would be uniform but penalize every success with an extra cycle. AHB keeps OKAY single-cycle — optimize the common case.
• Enforced OKAY-during-wait vs free HRESP during waits. Requiring HRESP=OKAY during simple waits keeps wait-vs-error unambiguous, at the cost of a constraint on the subordinate. Allowing arbitrary HRESP during waits would blur the distinction. AHB enforces OKAY-during-wait — unambiguous handling.

The throughline: HRESP is qualified by HREADY (commit on HREADY high), with non-OKAY responses required to be two-cycle and OKAY single-cycle. This gives uniform sampling, a guaranteed failure-reaction window, and an unambiguous wait-vs-error distinction — at the cost of pairing HRESP with HREADY, one extra cycle on failures, and a constraint on subordinate behavior during waits. These are well-judged trades that keep response handling simple and robust.

7. Industry Example

Trace response timing across the response types in one subsystem.

A processor accesses subordinates with varied behavior; its response handler applies the one timing rule throughout.

• Fast OKAY (single cycle). A read to SRAM: HREADY high, HRESP OKAY in one cycle. The processor samples HRESP on the HREADY-high cycle, sees OKAY, consumes the data, proceeds. One sampling rule, immediate success.
• Slow OKAY (waits, then commit). A read to flash: HREADY low for several cycles with HRESP=OKAY (just waits — not committed outcomes), then HREADY high with HRESP=OKAY (committed success) and valid data. The processor ignores HRESP during the waits (they're not final), and commits to OKAY on the HREADY-high cycle. The OKAY-during-wait was correctly read as "still waiting," not "done."
• ERROR (two-cycle). A read to an unmapped address: the default subordinate drives HRESP=ERROR with HREADY low (warning — the processor prepares to fault and cancels the pipelined next transfer), then HRESP=ERROR with HREADY high (committed failure). The processor commits to ERROR on the HREADY-high cycle and raises a fault. The warning cycle gave it the reaction window.
• RETRY/SPLIT (two-cycle, legacy full AHB). A transfer to a busy subordinate gets HRESP=RETRY (or SPLIT) across a HREADY-low warning then a HREADY-high completion. The processor commits to the response on the HREADY-high cycle and re-issues (RETRY) or is parked (SPLIT). Same timing rule, different dispatch.
• The uniform handler. In every case, the processor's response logic does the same thing: sample HRESP (and HRDATA) on the HREADY-high cycle, then dispatch on the value. The timing of sampling is identical across all responses; only the action differs. And it never confused a wait (OKAY, HREADY low) with a failure (non-OKAY two-cycle), because the protocol kept them distinct. One rule handled them all.

The example shows the timing rule as the unifying discipline: the processor sampled HRESP on the HREADY-high cycle for every response type, used the warning cycle of two-cycle responses to react, and never mistook a wait for an error. The single "act on HREADY high" rule, plus the two-cycle non-OKAY guarantee, made the response handling uniform, robust, and unambiguous.

8. Common Mistakes

9. Interview Insight

Response timing is a precise interview check — it tests whether you tie HRESP to HREADY and understand the two-cycle requirement.

The answer that lands states the rule and its consequences: "HRESP is qualified by HREADY — the transfer's committed outcome is the HRESP value on the cycle where HREADY is high, the completing cycle. So you always sample HRESP together with HREADY and act on it only when HREADY is high. OKAY is a single-cycle response; ERROR, RETRY, and SPLIT are mandatory two-cycle responses — a warning cycle with HREADY low, then a completion cycle with HREADY high. The two-cycle form gives the manager a reaction cycle before the response commits. And critically, during a simple wait HRESP must be OKAY — a non-OKAY response can never be a single cycle — so the two-cycle handshake is exactly how the bus distinguishes a plain wait from a real error." The qualify-by-HREADY rule, the two-cycle requirement, and the wait-vs-error disambiguation are the senior signals.

10. Practice Challenge

Reason from the response-timing rule.

1. State the rule. Give the one rule for when HRESP is the committed outcome.
2. Read the waveform. From Figure 2, explain why the OKAY during the wait is not the outcome and the OKAY on HREADY-high is.
3. Single vs two-cycle. Explain why OKAY is single-cycle and ERROR/RETRY/SPLIT are two-cycle.
4. Wait vs error. Explain how the protocol guarantees the manager can distinguish a wait from an error.
5. Synthesis. Explain how this one rule makes response handling uniform and robust.

11. Key Takeaways

• HRESP is qualified by HREADY — the transfer's committed outcome is the HRESP value on the cycle where HREADY is high (the completing cycle). Always sample HRESP with HREADY.
• While HREADY is low, HRESP is not final — a simple wait keeps HRESP=OKAY; a two-cycle ERROR/RETRY/SPLIT uses the low cycle as a warning.
• OKAY is single-cycle; ERROR/RETRY/SPLIT are mandatory two-cycle (warning with HREADY low, then completion with HREADY high) — the two-cycle form gives the manager a reaction window.
• A non-OKAY response can never be single-cycle, and HRESP must be OKAY during simple waits — so the two-cycle handshake cleanly distinguishes a wait from a real error.
• The manager captures HRESP on HREADY high (like HRDATA), then dispatches on the value — one uniform sampling rule, response-specific actions.
• The rule delivers uniform handling, a guaranteed failure-reaction window, and an unambiguous wait-vs-error distinction — simple and robust across all response types.

12. What Comes Next

You now know the unified response-timing rule. The next chapters detail the most important two-cycle response and the manager's handling:

• 7.6 — The Two-Cycle ERROR Response (coming next) — the exact cycle-by-cycle ERROR handshake and why it's mandatory.
• 7.7 — How the Master Reacts (coming soon) — the manager's handling of each response type (OKAY/ERROR/RETRY/SPLIT).

To revisit the responses, see OKAY Response, ERROR Response, RETRY Response, and SPLIT Response. For the HREADY timing this builds on, see What HREADY Means and The Data Phase. For the broader protocol map, see the AMBA family overview.