HRESP

This chapter covers HRESP, the response signal — how a subordinate tells the manager whether an access succeeded or failed. In modern AHB it is a single bit (OKAY or ERROR), but the ERROR case is more interesting than it looks: it uses a deliberate two-cycle protocol, and understanding why reveals something fundamental about how a pipelined bus handles failure. We give the encoding, walk the two-cycle error sequence, explain the pipeline reason behind it, note the legacy RETRY/SPLIT responses, and clarify what an error does (report failure) and does not do (undo a completed write).

1. What Is It?

HRESP is the response signal driven by the selected subordinate in the data phase, reporting the outcome of the access. In AHB-Lite and AHB5 it is a single bit:

• OKAY (0): the access completed successfully.
• ERROR (1): the access failed (bad address, protection violation, a peripheral fault, the default subordinate catching an unmapped access).

OKAY is the normal case and completes in a single HREADY-high cycle. ERROR uses a two-cycle protocol: the subordinate signals ERROR with HREADYOUT low (first cycle), then ERROR with HREADYOUT high (second cycle), completing the errored transfer over two cycles.

The legacy full AHB used a 2-bit HRESP with four responses: OKAY, ERROR, RETRY (the subordinate cannot complete now; try the transfer again later), and SPLIT (the subordinate will release the bus and signal the arbiter when it can resume). RETRY and SPLIT were tied to multi-master arbitration and were notoriously complex; AHB5 removed them, leaving the clean OKAY/ERROR pair. We focus on the modern model and treat RETRY/SPLIT as historical context.

2. Why Does It Exist?

HRESP exists because a manager must know whether its access succeeded — and the two-cycle ERROR protocol exists because the bus is pipelined, so an error must be signalled in a way that lets the manager deal with the next transfer that is already in flight.

Why a response at all. Not every access can succeed. An access might target an unmapped address (caught by the default subordinate), violate a protection rule, or hit a peripheral that faults. The manager needs to know, so it can take corrective action — raise an exception, retry, log the fault. HRESP is the channel for that outcome. Without it, a failed access would either hang (no completion) or silently appear to succeed, both unacceptable. The OKAY response is equally important: it is the subordinate confirming the access is done so the manager can move on.

Why ERROR takes two cycles. Here is the subtle, important part. AHB is pipelined: when a transfer is in its data phase, the next transfer's address phase is already on the bus. Suppose the current transfer is about to error. If the error were reported in a single cycle simultaneously with completion, the manager would have no chance to react before the next (already-pipelined) transfer committed — it might let a transfer proceed that should have been abandoned given the error. The two-cycle protocol solves this: in the first cycle the subordinate drives ERROR with HREADY low, which the manager samples — this is a warning that an error is completing. Because HREADY is low, the next transfer has not committed, and the manager can cancel it (drive IDLE) during this cycle. In the second cycle, the subordinate drives ERROR with HREADY high, completing the errored transfer. The first cycle is the manager's chance to react to the pipeline; the second is the actual completion.

So HRESP exists to report success or failure, and the two-cycle ERROR exists specifically because the pipeline means the next transfer is already in flight when an error occurs — the extra cycle gives the manager a clean opportunity to cancel that next transfer before it commits. It is a direct consequence of pipelining, and it is why error handling on a pipelined bus is necessarily a two-step affair.

3. Mental Model

Model HRESP as a cashier's "approved" or "declined" — where "declined" comes with a one-beat warning because the next customer is already stepping up.

When your transaction is approved (OKAY), the cashier says "done" and you leave — one beat. But a decline (ERROR) is handled in two beats because the next customer is already approaching the counter (the pipeline). On the first beat, the cashier flashes "declining…" while holding the line (HREADY low) — this warns you, and crucially, it lets the next customer, who was about to commit their order, step back (the manager cancels the pipelined next transfer). On the second beat, the cashier finalizes the decline (HREADY high) and the line moves. The two beats exist precisely so the next customer is not committed before the decline is handled.

Watch a transfer that ends in error:

The model's lesson: OKAY is one beat; ERROR is two beats, with the first beat a warning that lets the pipelined next transfer be cancelled. The two-cycle dance is not bureaucracy — it is the mechanism that keeps a failing transfer from dragging an already-in-flight next transfer down with it.

4. Real Hardware Perspective

In hardware, the subordinate drives HRESP alongside HREADYOUT, and the two-cycle error is a specific coordinated sequence of those two signals.

For OKAY, the subordinate simply drives HRESP = OKAY and asserts HREADYOUT high when the access completes — one cycle, the normal path. For ERROR, the subordinate produces the two-cycle sequence on HRESP and HREADYOUT together:

• First error cycle: HRESP = ERROR, HREADYOUT = low. The low HREADYOUT means "not done yet," which (via the shared HREADY) holds the bus and signals the manager that something is happening; the ERROR on HRESP tells it what. The manager samples ERROR here.
• Second error cycle: HRESP = ERROR, HREADYOUT = high. Now the transfer completes (HREADY high) with the error recorded.

The manager's side of the sequence is the other half: when it samples ERROR in the first cycle (with HREADY low), it knows the current transfer is failing, and it must handle the next transfer it had already pipelined. Typically it changes that next transfer to IDLE (cancels it) so a transfer that should not proceed (given the error) does not commit. After the second error cycle completes the failed transfer, the manager can take its corrective action (raise an exception, etc.). This coordinated dance — subordinate drives two-cycle ERROR, manager samples cycle one and cancels the pipelined next transfer — is the full error protocol.

A key hardware point: the two-cycle requirement means subordinates must implement the error sequence correctly (not just assert ERROR for one cycle), and managers must sample and react to the first error cycle. A subordinate that asserted ERROR for only one cycle, or a manager that ignored the first error cycle, would violate the protocol. Verification environments specifically check the two-cycle error sequence because it is a common place for both subordinate and manager bugs.

5. System Architecture Perspective

At the system level, HRESP is the bus's error-reporting channel, and it connects to how the system handles faults, unmapped accesses, and protection violations.

The most common source of an ERROR response is the default subordinate (chapter on terminology / 2.1): when an access targets an address no real subordinate owns, the decoder selects the default subordinate, which returns ERROR via the two-cycle protocol. This is how a stray access — a wild pointer, a bad address-map configuration — produces a clean, diagnosable error rather than hanging the bus. So HRESP plus the default subordinate together turn "access to nowhere" into a defined fault the system can catch. This is a major robustness feature: without it, unmapped accesses would be silent hangs.

Protection violations also surface as ERROR. A protection unit that blocks a forbidden access (e.g., a user-mode access to a privileged region, using HPROT[1] from chapter 3.6) typically returns an ERROR response, so the offending master sees its access was refused. So HRESP is the channel through which security enforcement communicates a denial back to the manager. The combination — HPROT carries the access's privilege, the protection unit decides, HRESP reports the denial — is how AHB participates in system protection.

On the manager/software side, an ERROR response usually translates into a processor fault or exception. When a processor's access errors on the bus, the processor takes a bus-fault exception, and software (an exception handler) decides what to do — terminate the offending task, log the fault, etc. So HRESP is the bus-level event that becomes a software-visible fault, connecting the hardware protocol to the system's error-handling software. The two-cycle protocol ensures this fault is delivered cleanly without corrupting subsequent transfers, which matters because a fault often must precisely identify the faulting access.

So at the system level, HRESP is the spine of error handling: it lets unmapped accesses fault cleanly (with the default subordinate), lets protection denials be reported (with the protection unit), and becomes the processor faults that software handles. A system without a working HRESP path would hang on errors instead of handling them — which is why getting the error protocol right matters far beyond the single signal.

6. Engineering Tradeoffs

HRESP's design reflects choices about how much error machinery to carry.

• Two-cycle ERROR vs single-cycle. The two-cycle protocol adds a cycle to every error and requires both subordinate and manager to implement the dance, but it is what lets a pipelined bus cleanly cancel the already-in-flight next transfer. A single-cycle error would be simpler but could not give the manager time to react to the pipeline. AHB pays the extra cycle (errors are rare) for clean pipelined error handling.
• OKAY/ERROR only vs RETRY/SPLIT. Modern AHB's two responses are simple to implement and verify; legacy AHB's four (adding RETRY and SPLIT) offered more sophisticated flow control for multi-master systems but were complex and bug-prone. AHB5 chose simplicity by removing RETRY/SPLIT — the multi-master needs they served are now met by bus matrices and AHB-Lite. The trade is flow-control sophistication versus simplicity, resolved toward simplicity.
• Report-only vs guaranteed rollback. HRESP reports failure but does not mandate that an errored access had no effect. Guaranteeing rollback (atomic failure) would be more robust for software but far more complex for subordinates. AHB chooses report-only, leaving recovery semantics to the system — simpler hardware, more responsibility on software.
• Error in the protocol vs out-of-band. Carrying errors on HRESP (in-band, per access) ties the error directly to the access that caused it, which is precise, at the cost of the two-cycle protocol complexity. An out-of-band error mechanism (a separate interrupt) would decouple it but lose the per-access precision. AHB keeps errors in-band for precision.

The through-line: HRESP trades a little protocol complexity (the two-cycle error) for clean, precise, pipelined error reporting, while keeping the response set minimal (OKAY/ERROR) by shedding the legacy RETRY/SPLIT. It is error handling sized for a simple, pipelined bus: enough to fault cleanly, not so much as to burden every subordinate.

7. Industry Example

Trace HRESP through the common error scenarios on a real system.

• An unmapped access (default subordinate errors). Firmware dereferences a wild pointer to an address no subordinate owns. The decoder finds no match and selects the default subordinate, which returns the two-cycle ERROR: ERROR + HREADY low, then ERROR + HREADY high. The processor samples the error, cancels the next pipelined fetch, completes the errored access, and takes a bus-fault exception. Software's fault handler logs the bad address and terminates or recovers the offending task. Without HRESP and the default subordinate, this wild access would have hung the bus with no clue.
• A protection violation (protection unit errors). A user-mode task tries to access a privileged peripheral. The protection unit, seeing HPROT[1]=user and a privileged region, blocks the access and returns the two-cycle ERROR. The processor faults, and the OS handles the security violation. HRESP is how the denial reached the processor.
• A normal successful access (OKAY). The overwhelming majority of accesses succeed: the subordinate returns OKAY in one HREADY-high cycle, the manager proceeds, no fault. OKAY is the silent, common path that makes the rare ERROR meaningful.
• The pipeline cancellation in action. Consider the wild-pointer fetch above with a fetch already pipelined behind it. When the processor samples ERROR in the first error cycle, it sees that the current fetch failed and drives the next transfer to IDLE — cancelling the speculative next fetch that should not proceed given the fault. The two-cycle protocol gave it exactly the cycle it needed to do this cleanly. On a single-cycle-error bus, that next fetch might have committed before the fault was handled.

Every error in the system flows through HRESP's two-cycle protocol: the default subordinate and protection unit are the common error sources, the processor turns the error into a fault, and the first error cycle lets the pipeline be cleaned up. The OKAY path is the quiet default that makes all of this the exception rather than the rule.

8. Common Mistakes

9. Interview Insight

HRESP questions almost always centre on the two-cycle error and why it is two cycles.

The answer that lands gives the encoding and nails the two-cycle rationale: "HRESP in modern AHB is one bit — OKAY or ERROR. OKAY completes in one HREADY-high cycle. ERROR is a two-cycle protocol: first ERROR with HREADY low, then ERROR with HREADY high. The two cycles exist because the bus is pipelined — when the error is first signalled, the next transfer's address phase is already on the bus, so the first cycle lets the manager cancel that next transfer before it commits. Legacy AHB also had RETRY and SPLIT, removed in AHB5." Explaining why two cycles — the pipeline cancellation — is the senior discriminator.

10. Practice Challenge

Reason from the two-cycle protocol and the pipeline.

1. State the encoding. Give the modern HRESP values and how many cycles each takes, plus the legacy responses.
2. Explain the two cycles. In three sentences, explain the two-cycle ERROR sequence and why it is two cycles.
3. Read the waveform. In Figure 2, identify the warning cycle and the completion cycle, and what the manager does with the next transfer.
4. Trace an unmapped access. Walk a wild-pointer access through the default subordinate, HRESP, and the processor fault.
5. Spot the bug. A subordinate asserts ERROR for one cycle. Explain what breaks and the correct sequence.

11. Key Takeaways

• HRESP reports access outcome: in modern AHB it is one bit — OKAY (succeeded) or ERROR (failed). Legacy full AHB also had RETRY and SPLIT, removed in AHB5.
• OKAY completes in one HREADY-high cycle; ERROR is a two-cycle protocol — ERROR with HREADY low, then ERROR with HREADY high.
• The two-cycle ERROR exists because of pipelining — the first cycle warns the manager while the bus is held, letting it cancel the already-pipelined next transfer before it commits.
• ERROR reports failure but does not guarantee rollback — whether an errored write had effect is subordinate-dependent; recovery is software's responsibility.
• HRESP is the system's error-reporting spine — the default subordinate errors on unmapped accesses, protection units error on violations, and the processor turns ERROR into a fault software handles.
• Both sides must implement the protocol — subordinates drive the full two-cycle ERROR, managers sample the first cycle and cancel the next transfer. A one-cycle error is a classic bug.

12. What Comes Next

You now know how outcomes are reported. The next chapter covers how a subordinate knows it is the one being addressed:

• 3.10 — HSEL (coming next) — the decoder-driven subordinate select, how a subordinate knows it is addressed, and its relationship with HREADY.
• 3.11 — HMASTER & HMASTLOCK (coming soon) — the multi-master signals identifying the current master and locked sequences.

To revisit the completion signalling HRESP rides alongside, see HREADY & HREADYOUT and The Data Phase; for the default subordinate and protection that generate errors, see Manager / Subordinate Terminology and HPROT. For the broader protocol map, see the AMBA family overview.