The Two-Cycle ERROR Response

Chapter 7.2 introduced ERROR as a two-cycle response; chapter 7.5 placed it in the response-timing rule. This chapter is the detailed, cycle-by-cycle treatment of that two-cycle handshake — exactly what the subordinate drives and what the master does in each of the two cycles, and a precise answer to why the two cycles are mandatory. The short version: because AHB pipelines, by the time a transfer signals an error in its data phase, the next transfer's address phase has already been issued. A single-cycle error would complete with no chance to stop that next transfer. The two-cycle error's first (warning) cycle gives the master exactly one guaranteed cycle to cancel the already-pipelined next transfer (drive its HTRANS to IDLE) before the error commits. This is a Critical-rated mechanism and a frequent interview question.

1. What Is It?

The two-cycle ERROR response is the mandatory handshake by which a subordinate signals ERROR across two consecutive cycles:

• Cycle 1 (warning): the subordinate drives HRESP=ERROR with HREADY low. This is the warning — "an error is coming, the transfer is not done yet."
• Cycle 2 (completion): the subordinate drives HRESP=ERROR with HREADY high. The errored transfer completes; the master commits to the ERROR.

The crucial detail is what the master does in cycle 1: it uses the warning cycle to drive the next transfer's HTRANS to IDLE — cancelling the transfer the pipeline already issued. Then in cycle 2, when the error commits, the master begins its error handling (raise a fault, etc.). So the two cycles have distinct roles: cycle 1 is the master's reaction window (cancel the next transfer), cycle 2 is the commit (the error completes, handling begins). This is the precise mechanism behind the "guaranteed reaction window" mentioned in chapters 7.2 and 7.5.

2. Why Does It Exist? (Why two cycles are mandatory)

The two cycles are mandatory because of the pipeline: by the time a transfer signals its error (in its data phase), the master has already issued the next transfer's address phase — and the master needs a guaranteed cycle to cancel it before the error completes.

Trace the timing. Transfer T1's address phase happens, then its data phase one cycle later (the address-leads-data overlap, chapter 5.2). During T1's data phase — exactly when the subordinate would signal T1's error — T2's address phase is already on the bus (it overlaps T1's data phase). So at the moment the error is known, T2 has already been issued. If the error completed in a single cycle, T2 would proceed into its data phase immediately, with no opportunity for the master to stop it. That is dangerous: T2 might be a follow-on access that should not happen given T1 failed (e.g., the next beat of a burst into a failing region, or a dependent access). So the master must be able to cancel T2 — and that requires a cycle in which the error is known but not yet committed. The two-cycle handshake provides exactly that: cycle 1 (warning) is the cycle where the error is known (HRESP=ERROR) but the transfer isn't done (HREADY low), giving the master a cycle to drive T2 to IDLE. The two cycles are mandatory because the pipeline guarantees T2 is already issued, and cancelling it requires a reaction cycle.

The reason the warning is signaled as HREADY low (not some separate signal) is that it reuses the existing pacing mechanism: holding HREADY low for one cycle delays completion, which is exactly what is needed — the error is presented (HRESP=ERROR) but the transfer isn't completed yet, giving the reaction cycle. So the two-cycle error is built from the same HREADY/HRESP signals (no new signal): present the error value, hold off completion one cycle (HREADY low), then complete (HREADY high). This elegance — reusing HREADY to create the reaction window — is why the two-cycle error needs no extra machinery, just a defined sequence (chapter 7.5).

The reason the master cancels T2 specifically (drives HTRANS to IDLE) is that IDLE is the "no transfer" type (chapter on HTRANS): driving HTRANS=IDLE in T2's address phase tells the bus "ignore this — no transfer here." So the master's cancellation is concrete: change the next transfer's HTRANS to IDLE during the warning cycle, so it does not proceed as a real transfer. This is why the reaction window matters — it's the cycle in which the master can drive IDLE. Without it, T2's address phase would already have committed to a real transfer. So the two-cycle handshake and the IDLE cancellation work together: the warning cycle gives the master the chance to drive IDLE, cancelling the follow-on transfer cleanly.

3. Mental Model

Model the two-cycle ERROR as an air-traffic controller calling "abort!" one beat before the runway is committed — that one-beat warning is exactly enough time for the next plane, already on approach, to pull up.

Planes land in a steady stream (the pipeline) — as one lands (T1's data phase), the next is already on final approach (T2's address phase, already issued). Now suppose the landing plane has a problem (T1 errors). The controller can't just instantly close everything — the next plane is already committed to its approach. So the controller calls "abort!" one beat before finalizing (the warning cycle — error known, not yet committed), and that one beat is exactly enough for the approaching plane to pull up (the master drives T2 to IDLE). Then the controller finalizes the first plane's situation (the error commits, cycle 2). If the controller had no warning beat — if everything finalized instantly — the approaching plane would have already landed into the problem. The one-beat warning is what makes the abort possible.

This captures the two-cycle error: the next plane already on approach = T2's address already issued by the pipeline; the one-beat "abort" warning = cycle 1 (error known, HREADY low, not committed); the approaching plane pulling up = the master driving T2 to IDLE; finalizing = cycle 2 (error commits, HREADY high). The warning beat exists precisely because the next item is already in flight and needs a moment to be waved off.

Watch the two-cycle ERROR cancel the next transfer:

The model's lesson: the warning beat (cycle 1) is exactly enough time to wave off the already-approaching next transfer (drive it to IDLE) before the error finalizes (cycle 2). In the waveform, the master drives HTRANS to IDLE during the warning cycle, cancelling the next transfer; then the error commits. One beat of warning, one clean cancellation.

4. Real Hardware Perspective

In hardware, the two-cycle ERROR is generated by the subordinate's response state machine and handled by the master's response logic, with the IDLE-cancellation being the master's concrete reaction in the warning cycle.

The subordinate side is a small state machine (chapter 7.2): on detecting an error in the data phase, instead of completing OKAY, it enters a two-cycle error sequence — first state drives HRESP=ERROR, HREADY=0 (warning); second state drives HRESP=ERROR, HREADY=1 (completion); then back to normal. So the subordinate guarantees the two-cycle form by construction — it cannot emit a single-cycle error. This is the hardware realization of "non-OKAY responses are mandatory two-cycle" (chapter 7.5): the subordinate's FSM simply has no path that completes an error in one cycle.

The master side does two things across the two cycles. In cycle 1 (it sees HRESP=ERROR with HREADY low — the warning), the master's control logic drives the next transfer's HTRANS to IDLE, cancelling it. In cycle 2 (HRESP=ERROR with HREADY high), the master captures the ERROR (gated on HREADY high, chapter 7.5) and triggers its error handling. So the master needs logic that, on seeing the warning, both cancels the next transfer and prepares to commit the error on the following cycle. This is a specific, designed behavior — a master must be built to recognize the warning cycle and react, not just to sample the final response. A master that ignored the warning cycle and only acted on the completing cycle would be too late to cancel the next transfer.

The IDLE cancellation is concrete hardware: HTRANS is a master output (chapter on HTRANS), and IDLE is the encoding meaning "no transfer." During the warning cycle, the master drives HTRANS=IDLE for the address phase that would otherwise launch the next transfer. So the bus sees IDLE in that address phase and does not treat it as a real transfer — the next transfer is cancelled. The master may then re-issue the intended next transfer later (after handling the error) or abandon it, depending on its policy. The key hardware point is that the master has the cycle (the warning) in which to drive IDLE, which is what the two-cycle handshake guarantees.

A hardware subtlety about bursts: the two-cycle error is especially important mid-burst. When a beat of a burst errors, the next beat's address is already issued (pipelined). The warning cycle lets the master drive HTRANS to IDLE, terminating the burst cleanly rather than launching the next (possibly failing) beat (chapters 7.7 and the burst module). So the two-cycle error's reaction window is what enables clean burst termination on error — a common and important case. Without it, a burst would blindly continue into more failing beats. This is one of the most practically important uses of the two-cycle handshake.

5. System Architecture Perspective

At the system level, the two-cycle ERROR is what makes error handling safe in a pipelined bus — it is the mechanism that prevents a failure from silently dragging the already-issued next transfer along with it, enabling clean error containment and burst termination.

The core system value is containment: without the reaction window, a failed transfer would be followed immediately by the next transfer (already pipelined), which might compound the problem — another access to a failing region, a dependent operation that shouldn't run, or the next beat of a burst that should be aborted. The two-cycle error lets the master contain the failure by cancelling that next transfer. So the two-cycle handshake is the bus's mechanism for stopping the bleed — ensuring a failure doesn't automatically propagate into the next transfer. This containment is essential for robust error handling: a fault should halt related activity, not blindly continue.

The mechanism is especially critical for burst termination on error (chapters 7.7, 8.x). A burst is a sequence of pipelined beats; if one beat errors, the master usually must abort the rest (the burst's premise is broken). The two-cycle error's reaction window is precisely what lets the master drive IDLE to terminate the burst cleanly, rather than launching the next beat. So at the system level, the two-cycle error enables correct burst behavior under failure — a slow or failing subordinate mid-burst is handled cleanly. Bursts are common and performance-critical, so this is a major practical role of the mechanism.

The two-cycle error also reflects a general architectural principle: in a pipelined system, error signaling needs a reaction window proportional to the pipeline depth. AHB's pipeline is shallow (one stage of address-leads-data), so one warning cycle suffices to cancel the one already-issued transfer. A deeper pipeline would need a correspondingly larger window or a different mechanism. So the two-cycle error is AHB's pipeline-depth-matched error-reaction mechanism — exactly one cycle of warning for exactly one stage of pipeline. This is a clean, minimal design: the reaction window is sized to the pipeline. Understanding this connects the two-cycle error to a broader lesson — pipelined protocols must provide error-reaction windows matched to their depth, and AHB's two-cycle error is the minimal instance of that principle. (AXI handles this differently, with errors carried per-transaction on the response channel, fitting its outstanding-transaction model.)

6. Engineering Tradeoffs

The two-cycle ERROR embodies AHB's minimal-reaction-window design.

• Two-cycle (with reaction window) vs single-cycle error. The two-cycle form gives the master a guaranteed cycle to cancel the pipelined next transfer (safe containment, clean burst abort) at the cost of one extra cycle on errors. A single-cycle error would be faster but unsafe in the pipeline (no chance to stop the next transfer). AHB requires two cycles — safety is essential; the cost falls only on rare errors.
• Reuse HREADY vs a dedicated warning signal. The warning is created by holding HREADY low (reusing the pacing signal), needing no new signal. A dedicated "error-coming" signal would be redundant. AHB reuses HREADY — minimal signaling.
• IDLE-cancellation vs automatic hardware abort. The master cancels the next transfer by driving HTRANS=IDLE (explicit, master-controlled), keeping the master in control of its pipeline. An automatic hardware abort would be less flexible. AHB uses the master's IDLE-drive — the master decides, consistent with "report not fix" (chapter 7.2).
• One-cycle window vs deeper. AHB's one warning cycle matches its one-stage pipeline. A deeper window would be needed for a deeper pipeline but would cost more on every error. AHB's window is minimal — exactly sized to its pipeline depth.

The throughline: the two-cycle ERROR is the minimal pipeline-matched reaction mechanism — one warning cycle (via HREADY low) lets the master cancel the one already-issued next transfer (via HTRANS=IDLE) before the error commits. The cost is one extra cycle on errors; the benefit is safe failure containment and clean burst termination in a pipelined bus. It is a tight, elegant design — reaction window sized exactly to the pipeline, built from existing signals.

7. Industry Example

Trace the two-cycle ERROR terminating a burst on a failed beat.

A processor issues a burst write into memory that crosses into an unmapped region partway through.

• The burst proceeds normally. The first beats hit mapped memory and complete OKAY, pipelined — each beat's address phase overlapping the previous beat's data phase. The burst is streaming.
• A beat crosses into unmapped space. One beat's address falls in unmapped space. The default subordinate (for that address) will return ERROR. Critically, by the time this beat reaches its data phase and the error is known, the next beat's address phase has already been issued (the burst is pipelined).
• Cycle 1 — the warning. The default subordinate drives HRESP=ERROR with HREADY low. The processor sees the warning and, in this cycle, drives HTRANS to IDLE for the next beat — cancelling it. The burst is being terminated: the next beat will not launch into the failing region.
• Cycle 2 — the commit. The subordinate drives HRESP=ERROR with HREADY high; the errored beat completes. The processor commits to the error, raises a bus fault, and its handler deals with the failed burst (logs it, reports the bad address, etc.). The burst is cleanly terminated — no further beats issued.
• What a single-cycle error would have done. Had the error been single-cycle, the errored beat would have completed immediately, and the next beat — already issued — would have proceeded into the unmapped region too, generating a second error (or worse, if it hit something access-sensitive). The processor would have had no chance to stop it. The two-cycle warning prevented this cascade.
• The reaction window in action. The whole clean termination hinged on the warning cycle: that one cycle was exactly when the processor drove IDLE to cancel the next beat. The two-cycle error gave the processor the moment it needed to stop the burst before it ran further into the fault.

The example shows the two-cycle error's practical payoff: a burst crossing into a bad region is terminated cleanly because the warning cycle let the processor cancel the next beat before it launched. The single-cycle alternative would have let the failure cascade into the already-issued next beat. The two-cycle handshake's reaction window is what makes clean error containment — especially mid-burst — possible.

8. Common Mistakes

9. Interview Insight

The two-cycle ERROR is a Critical, frequently-asked interview topic — explaining why two cycles separates surface knowledge from real understanding.

The answer that lands explains the mechanism and the pipeline rationale: "The two-cycle ERROR is signaled across two cycles: cycle one drives HRESP=ERROR with HREADY low — the warning — and cycle two drives HRESP=ERROR with HREADY high — the completion. It's mandatory because of the pipeline: by the time a transfer errors in its data phase, the next transfer's address phase has already been issued, since address leads data by a cycle. A single-cycle error would let that next transfer proceed before the master could stop it. The warning cycle gives the master exactly one cycle to react — it drives the next transfer's HTRANS to IDLE, cancelling it — before the error commits on the second cycle. This is especially important mid-burst: it lets the master cleanly terminate the burst instead of launching the next failing beat." The pipeline rationale, the HTRANS-to-IDLE cancellation, and the burst-termination payoff are the senior signals.

10. Practice Challenge

Reason from the two-cycle handshake and its rationale.

1. State the handshake. Give what the subordinate drives in each of the two cycles.
2. Master actions. State what the master does in cycle 1 versus cycle 2.
3. Explain the necessity. Tie the two-cycle requirement to the pipeline and the already-issued next transfer.
4. Read the waveform. From Figure 3, identify when the master drives HTRANS to IDLE and why.
5. Burst case. Explain how the two-cycle error enables clean burst termination on an errored beat.

11. Key Takeaways

• The two-cycle ERROR is: cycle 1 = HRESP=ERROR with HREADY low (warning); cycle 2 = HRESP=ERROR with HREADY high (completion).
• It is mandatory because of the pipeline — by the time a transfer errors, the next transfer's address phase is already issued; the warning cycle gives the master a guaranteed cycle to cancel it.
• The master cancels the next transfer by driving its HTRANS to IDLE during the warning cycle — and must act in that cycle, not on completion (too late).
• In cycle 2 the master commits — samples ERROR (gated on HREADY high) and begins error handling (read data invalid, write state uncertain).
• It enables clean burst termination on error — the warning cycle lets the master drive IDLE to stop the burst instead of launching the next failing beat.
• It is the minimal pipeline-matched reaction mechanism — one warning cycle for one stage of pipeline — built from existing HREADY/HRESP/HTRANS signals, illustrating the general principle that pipelined protocols need error-reaction windows matched to their depth.

12. What Comes Next

You now understand the two-cycle ERROR in detail. The next chapter generalizes to the master's handling of all responses:

• 7.7 — How the Master Reacts (coming next) — the master's response-handling state machine across OKAY, ERROR, RETRY, and SPLIT.
• 7.8 — AHB-Lite Response Simplification (coming soon) — how AHB-Lite reduces responses to OKAY/ERROR only.

To revisit the ERROR basics, see ERROR Response and the timing rule in Response Timing. For the pipeline that makes the warning cycle necessary, see The Two-Phase Pipeline and Address Phase Leads Data Phase. For the IDLE transfer type used to cancel, see IDLE Transfers. For the broader protocol map, see the AMBA family overview.