OKAY Response

This opens Module 7 — Responses, which examines what a subordinate signals about the outcome of a transfer, separate from its timing. Module 6 was all about HREADY — when a transfer completes. This module is about HRESP — how it completes: successfully (OKAY) or with a failure (ERROR, and the legacy RETRY/SPLIT). This first chapter covers the most common outcome by far: OKAY, the successful-transfer response. The central idea is that HREADY and HRESP are two independent axes — HREADY is timing (is it done this cycle?), HRESP is outcome (did it succeed?). OKAY is the success outcome, the default that the overwhelming majority of transfers end with, requiring no special handling from the manager.

1. What Is It?

HRESP is the subordinate's response signal — it reports the outcome of a transfer. OKAY is the HRESP value meaning the transfer completed successfully.

The key relationship is between HRESP and HREADY, and the key insight is that they are orthogonal:

• HREADY is the timing axis: is the transfer complete this cycle (high) or still waiting (low)?
• HRESP is the outcome axis: did the transfer succeed (OKAY) or fail (ERROR)?

A transfer completes successfully on the cycle where HREADY is high and HRESP is OKAY. That is the combined condition: HREADY high says "done now," HRESP OKAY says "and it succeeded." OKAY is the default outcome — the value HRESP carries for every normal, successful transfer, which is the vast majority. So while Module 7 spends most of its chapters on the failure responses (because they need explaining), the response you will see almost always is OKAY: the quiet signal that everything worked.

2. Why Does It Exist?

OKAY — and the HRESP response signal generally — exists because the manager needs to know not just when a transfer finished but whether it succeeded. Timing alone (HREADY) is not enough; the manager must also learn the outcome, and OKAY is the "all good" outcome.

Consider what the manager knows from HREADY alone: that the transfer completed this cycle. But "completed" is not the same as "succeeded" — a transfer could complete because the subordinate gave up (an error), not because it worked. So the manager needs a second signal that distinguishes success from failure. That is HRESP, and OKAY is its success value. Without HRESP, the manager could not tell a successful read from a failed one — both would just "complete" via HREADY. So OKAY exists as the explicit "this transfer succeeded" signal, separating success from the failure outcomes. The response signal disambiguates how a completion happened.

The reason OKAY is the default (rather than requiring positive assertion of success per transfer) is that success is the overwhelming common case, so it is the natural baseline. A normal subordinate completing a normal transfer drives HRESP=OKAY; only when something goes wrong does it drive a different value (ERROR). So OKAY being the default means the interesting signal is the absence of OKAY — an error. This is an efficient design: the common case (success) is the quiet default, and the rare case (failure) is the explicit deviation. OKAY exists as that quiet baseline against which failures stand out.

OKAY also exists to make the orthogonality clean: because OKAY is a separate signal from HREADY, the protocol cleanly separates timing from outcome. A slow transfer (many wait states) can still be OKAY (slow but successful); a fast transfer can be ERROR (quick failure). So OKAY existing on its own axis is what lets the protocol express all four combinations of fast/slow × success/failure. This separation is why a subordinate can take its time (HREADY low) and still succeed (HRESP OKAY) — the two are not conflated. OKAY exists partly to keep outcome independent of timing.

3. Mental Model

Model HRESP/OKAY versus HREADY as a kitchen where "is the dish ready?" and "did the dish come out right?" are two separate questions — OKAY is the chef nodding "it's good."

When you order food (issue a transfer), there are two independent things you want to know. First, is it ready yet? — the timing (HREADY: the dish arrives now, or you're still waiting). Second, did it come out right? — the outcome (HRESP: the chef nods "OKAY, it's good," or says "sorry, we couldn't make it" — ERROR). These are genuinely independent: a dish can arrive quickly and be perfect (fast + OKAY), take a long time and be perfect (slow + OKAY — the chef took care over it), or come back as "we can't make that" (ERROR). The "ready?" question (HREADY) and the "came out right?" question (HRESP) are answered separately. OKAY is simply the chef's nod that the dish is good — the default for any normal order.

This captures the orthogonality: ready? = HREADY (timing), came out right? = HRESP (outcome), and OKAY = the "it's good" nod. A slow dish that's perfect (waits + OKAY) shows the two are independent — taking time doesn't mean it failed. Most orders just arrive and are fine (OKAY), which is why OKAY is the quiet default.

Watch OKAY accompany a transfer that takes wait states:

The model's lesson: OKAY is the "it's good" nod — independent of how long the transfer took. In the waveform, HRESP stays OKAY through the wait states; the waits delay when it completes (HREADY) but not that it succeeds (HRESP OKAY). Slow but successful.

4. Real Hardware Perspective

In hardware, HRESP is a subordinate output (like HREADYOUT, aggregated by the interconnect from the data-phase subordinate), and OKAY is typically its reset/default encoding — so a subordinate that does nothing special naturally signals OKAY.

HRESP is driven by the subordinate currently in its data phase and routed by the interconnect to the manager, exactly parallel to how HREADY is sourced (chapter 6.6). So HRESP is associated with the same data-phase subordinate, on the same registered-select basis — the response and the readiness come from the same subordinate for the same transfer. This is why response timing tracks HREADY timing (chapter 7.5): both are data-phase signals from the responding subordinate. In hardware, OKAY is generally the default/idle encoding of HRESP, so a subordinate drives OKAY unless it specifically detects an error condition — success is the do-nothing-special output.

The encoding of HRESP differs by AHB version, and OKAY is the baseline in all of them:

• In full AHB (AHB2), HRESP is 2 bits encoding four responses: OKAY, ERROR, RETRY, SPLIT. OKAY is one encoding (the success one).
• In AHB-Lite and AHB5, the response is simplified to a single bit: OKAY or ERROR (RETRY/SPLIT are removed, chapter 7.8). OKAY is the de-asserted/default state.

So across versions, OKAY is the common success encoding; the failure encodings vary (full AHB has more). This chapter focuses on OKAY (success), which is identical in meaning everywhere; chapter 7.2 covers ERROR, and 7.3/7.4 the legacy RETRY/SPLIT.

The single-cycle nature of OKAY is a hardware simplicity: unlike ERROR (which is a mandatory two-cycle handshake, chapters 7.2/7.6), OKAY is a plain single-cycle response — when the subordinate is ready and successful, it drives HREADY high and HRESP OKAY in the same cycle, and the transfer completes. So OKAY requires no special multi-cycle protocol; it is the simplest possible response. This is part of why OKAY needs no special manager handling: it is just "completed, and fine," signaled in one cycle alongside the normal completion. The complexity in Module 7 is all in the failure responses; OKAY is the trivial, default case.

A hardware note on reads: for a successful read, HRESP=OKAY accompanies valid HRDATA on the completing cycle (chapter 5.4). So OKAY and the valid data arrive together — the subordinate says "here is your data, and it's good" in one cycle. For a write, OKAY means the write was accepted successfully. In both cases OKAY is the subordinate confirming the transfer did what it was supposed to. The data path (HRDATA) and the outcome (HRESP OKAY) align on the completing cycle.

5. System Architecture Perspective

At the system level, OKAY being the quiet default shapes how the whole system treats responses: success is assumed and unremarkable, while errors are the exceptional events that drive handling logic. This "success is silent" model keeps the common path simple.

Because OKAY is the default outcome of the overwhelming majority of transfers, system logic is built around the assumption of success, with error handling as the exception path. A manager's normal datapath just consumes read data and proceeds, treating OKAY as "nothing to see here"; only on a non-OKAY response does it divert to error-handling logic (chapter 7.7). So the system's response handling is structured as "fast path for OKAY, exception path for errors" — which keeps the common case efficient. OKAY's role as the silent default is what allows this: success requires no work, so the bulk of transfers flow through with no response-handling overhead. The architecture optimizes for the OKAY case because it is nearly all cases.

This also means OKAY is where performance lives and errors are where correctness/robustness live. Throughput is determined by how fast OKAY transfers stream (with their wait states, Module 6); error handling is about correctly detecting and recovering from the rare failures. So an architect tunes the OKAY path for throughput and designs the error path for correctness — two different concerns on the two outcomes. OKAY transfers, with their timing (HREADY) behaviour, are the performance story; the failure responses are the robustness story. Separating them (the orthogonality) lets each be designed for its purpose.

The orthogonality of HREADY and HRESP has a clean architectural payoff: a subordinate can be slow (many waits) yet reliable (always OKAY), or fast yet occasionally failing — and the system handles each correctly because timing and outcome are separate. A slow-but-reliable subordinate (flash that always succeeds after waits) and a fast-but-fallible one (a peripheral that may error) are both expressible and both handled. So the system can mix subordinates with different timing and different reliability profiles, because the protocol separates the two axes. This is the same composability theme (Module 6) extended to outcomes: timing and outcome are independent contracts, each honored separately, letting diverse subordinates coexist.

6. Engineering Tradeoffs

OKAY and the HRESP design reflect AHB's separate-timing-from-outcome choice.

• Separate HRESP vs encoding outcome in HREADY. AHB uses a separate HRESP signal for outcome, orthogonal to HREADY's timing. Encoding outcome into the completion timing (e.g., "complete-with-error" as a special timing) would conflate the two and be less clear. AHB separates them — two clean axes, at the cost of an extra signal.
• OKAY as silent default vs explicit success. Making OKAY the default (success is the do-nothing-special outcome) keeps the common case trivial — most transfers need no response logic. Requiring explicit per-transfer success assertion would add overhead to the common case. AHB makes success the quiet default — efficiency for the common path.
• Single-cycle OKAY vs uniform multi-cycle responses. OKAY is a simple single-cycle response while ERROR is two-cycle (chapter 7.6). Making all responses uniform (e.g., all two-cycle) would be simpler to reason about but would penalize the common OKAY case with extra cycles. AHB keeps OKAY single-cycle (fast common path) and pays the two-cycle cost only on the rare ERROR.
• Orthogonal axes vs combined status. Keeping timing and outcome orthogonal lets all fast/slow × success/fail combinations be expressed cleanly. A combined status encoding might save a signal but would muddle the independent concerns. AHB keeps them orthogonal — clarity and expressiveness.

The throughline: OKAY is the silent, single-cycle, default success outcome on an HRESP axis kept orthogonal to HREADY's timing. The design optimizes the common case (success is free and fast) while keeping outcome cleanly separate from timing — at the small cost of a dedicated response signal and asymmetry between OKAY (single-cycle) and ERROR (two-cycle). This is a deliberate optimization for the reality that almost all transfers succeed.

7. Industry Example

Trace OKAY across the normal operation of a subsystem.

A processor runs normal code, accessing SRAM, flash, and peripherals — almost all transfers succeed.

• SRAM read — fast OKAY. The processor reads SRAM. It completes in one cycle: HREADY high, HRESP OKAY, valid data. Fast and successful — the common case. The processor consumes the data and proceeds with no response handling.
• Flash read — slow OKAY. The processor reads flash. Flash inserts several wait states (HREADY low) while it fetches, with HRESP=OKAY throughout, then completes (HREADY high, HRESP OKAY) with valid data. Slow but successful — the waits delayed completion but the outcome is OKAY. The processor waited, then consumed the data normally. No error handling — a wait is not a failure.
• Peripheral write — OKAY. The processor writes a peripheral register. The peripheral accepts the write (possibly after a wait or two) and signals HREADY high, HRESP OKAY. The write succeeded; the processor moves on.
• The overwhelming pattern. Across millions of transfers in normal operation, the response is OKAY virtually every time. The processor's datapath streams through OKAY transfers — fast or slow — with no response-handling overhead. OKAY is the silent default that the whole system runs on. Throughput is determined by the timing of these OKAY transfers (their wait states), not their outcome (always OKAY).
• The rare exception. Only occasionally — an access to an unmapped address, a permission violation, a genuine hardware fault — does HRESP deviate to ERROR, triggering the manager's exception path (chapter 7.2/7.7). These are the exceptions that prove the rule: OKAY is normal, ERROR is the rare event that needs handling.

The example shows OKAY as the quiet backbone of normal operation: nearly every transfer, fast or slow, ends OKAY, and the system streams through them with no special handling. The waits affect timing (throughput), not outcome. OKAY is what "everything working" looks like on the bus — which is almost all the time.

8. Common Mistakes

9. Interview Insight

The OKAY response and the HREADY/HRESP orthogonality are common interview checks — they test whether you cleanly separate timing from outcome.

The answer that lands separates the two axes cleanly: "OKAY is the successful-transfer response — the value HRESP carries when a transfer completes successfully. The key is that HREADY and HRESP are orthogonal: HREADY is timing — is the transfer done this cycle — and HRESP is outcome — did it succeed or fail. A transfer completes successfully on the cycle where HREADY is high and HRESP is OKAY. OKAY is the default, the common case — most transfers end OKAY with no special handling — and it can follow wait states, so a transfer can be slow but still OKAY. Waits affect timing, not outcome. It's a single-cycle response, unlike the two-cycle ERROR." The orthogonality and the slow-but-successful point are the senior signals.

10. Practice Challenge

Reason from the timing/outcome orthogonality.

1. State the axes. Explain what HREADY and HRESP each report and why they are orthogonal.
2. Completion condition. State the exact condition under which a transfer completes successfully.
3. Read the waveform. From Figure 2, explain why the transfer is OKAY despite the wait states.
4. Correct the misconception. Explain why "HREADY low means failure" and "HREADY high means success" are both wrong.
5. Architectural rationale. Explain why making OKAY the silent default keeps the common path efficient.

11. Key Takeaways

• HRESP reports the transfer outcome; OKAY is the successful-transfer response — the default outcome of a normal transfer.
• HREADY and HRESP are orthogonal axes: HREADY is timing (done this cycle?), HRESP is outcome (succeeded?). A transfer completes successfully when HREADY is high AND HRESP is OKAY.
• OKAY can follow wait states — a transfer can be slow (many waits) but successful. Waits affect timing, not outcome; slow ≠ failed.
• OKAY is the silent, single-cycle default — it needs no special handling (unlike the two-cycle ERROR). Across versions, OKAY is the common success encoding (full AHB: OKAY/ERROR/RETRY/SPLIT; AHB-Lite/AHB5: OKAY/ERROR).
• Success is the quiet default; errors are the exception path — the system streams through OKAY transfers with no overhead and diverts only on non-OKAY.
• Never read HREADY as outcome — HREADY low isn't failure, HREADY high isn't success. Outcome is on HRESP, checked on the completing cycle.

12. What Comes Next

You now understand the success response. The next chapters cover the failure responses:

• 7.2 — ERROR Response (coming next) — the ERROR outcome, what triggers it, and the introduction to its mandatory two-cycle handshake.
• 7.3 / 7.4 (coming soon) — the legacy RETRY and SPLIT responses (full AHB only).

To revisit the timing axis this builds on, see What HREADY Means and The Data Phase. For how responses are sourced like HREADY, see HREADY vs HREADYOUT. For the broader protocol map, see the AMBA family overview.