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 reconsider that next transfer. The two-cycle error's first (warning) cycle gives the master exactly one guaranteed cycle in which it may cancel the already-pipelined next transfer (by driving its HTRANS to IDLE) before the error commits.

One point up front, because it is the single most common thing this topic gets wrong: the two cycles guarantee the master an opportunity to cancel — they do not oblige it to take one. The AMBA specification is explicit that a master may cancel the remaining transfers of a burst after an ERROR, and equally that it is acceptable to complete them. Section 7b below gives a checker that measures which choice a master made without failing the legal one.

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 warning cycle makes possible for the master. Address and control are captured on the rising HCLK edge at which HREADY is high — so while HREADY is held low the next transfer's address phase is still open, and whatever HTRANS the master presents by the end of the second cycle is what the bus actually captures. That is the whole mechanism: the HREADY-low cycle keeps the already-issued address phase uncommitted for exactly one more cycle, and the master may use it to change HTRANS to IDLE and cancel that transfer. In cycle 2 the errored transfer completes, the master samples the ERROR, and its error handling begins.

So the two cycles have distinct roles: cycle 1 is the decision window (the next transfer is issued but not yet captured), cycle 2 is the commit (the error completes, handling begins). Whether the master spends the decision window cancelling is its own policy — see the scope note in section 2b.

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). At the moment the error is known, T2 has already been issued. If the error completed in a single cycle, T2 would be captured at the very edge that delivered the error, with no opportunity to reconsider it. That matters when T2 is a follow-on access that should not happen given T1 failed — the next beat of a burst into a failing region, or a dependent access. For the master to have any say at all, there must be a cycle in which the error is known but the successor is 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. The two-cycle error is therefore built entirely from signals that already exist: present the error value, hold off completion for one cycle with HREADY low, then complete with HREADY high. Reusing HREADY to create the window is why the mechanism needs no extra machinery — only a defined sequence (chapter 7.5).

When a master does cancel T2 it does so by driving HTRANS to IDLE, because IDLE is the "no transfer" encoding: IDLE in T2's address phase tells the bus there is nothing to perform here. The cancellation is concrete rather than abstract — change HTRANS to IDLE before the capturing edge, and the value the bus records for that address phase is IDLE. Without the extra cycle there would be no edge at which a revised HTRANS could still be captured; T2's address phase would already have been sampled at the same edge that delivered the error.

That is the exact sense in which the two cycles are mandatory. The subordinate's two-cycle sequence is required so that the possibility exists. Exercising it is the master's decision, and section 2b sets out where that line falls.

2b. Scope — What Is Required, and of Whom

The two-cycle ERROR is often taught as one rule. It is really two rules with different owners and different force, and conflating them produces both bad RTL reviews and false verification failures.

Required of the subordinate. A non-OKAY response is a two-cycle response. In the first cycle the subordinate drives HRESP=ERROR with HREADYOUT low; in the second it drives HRESP=ERROR with HREADYOUT high. HRESP is held at ERROR across both cycles — a one-cycle ERROR, or an ERROR pulsed only on the completing cycle, is a protocol violation. This is not negotiable and is the thing to assert against a subordinate.

Permitted of the manager. On receiving an ERROR the manager may cancel the transfers it has already issued — for a burst, the remaining beats — by driving HTRANS to IDLE. The AMBA specification states this as a permission and explicitly allows the alternative: a manager may also complete the remaining transfers of the burst. Both behaviours are protocol-legal.

Two practical consequences follow, and they are the reason this distinction is worth a section of its own:

• Do not write manager must drive IDLE as a protocol assertion. A conformant manager that completes its burst after an ERROR will fail it, and the resulting bug report will be filed against a design that is behaving correctly. If your project genuinely requires cancellation, assert it — but label the check project policy, not protocol. Debug Lab 1 is exactly this failure.
• Do not write a subordinate that assumes cancellation. If the subordinate's next-state logic is built on "after an ERROR the manager will go IDLE", it will misbehave against a manager that continues. The subordinate must handle whatever legal HTRANS arrives next.

Scope for this chapter: AHB-Lite and AHB5, where HRESP is a single bit carrying OKAY or ERROR. Legacy full AHB has a two-bit HRESP that also encodes RETRY and SPLIT; those responses share the two-cycle shape described here but have different completion semantics and are covered separately in RETRY Response and SPLIT Response. Nothing on this page should be read as describing RETRY or SPLIT behaviour.

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. The subordinate guarantees the two-cycle form by construction — it has no state path that emits 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 has one obligation and one option. The obligation is in cycle 2: capture the ERROR on the rising edge where HREADY is high (chapter 7.5) and start error handling. The option is in cycle 1: having seen HRESP=ERROR with HREADY low, the master's control logic may drive the next transfer's HTRANS to IDLE, so that the value captured at the end of cycle 2 is IDLE rather than the transfer it originally issued.

A master built to react only on the completing cycle is not broken — it is a master whose policy is to let already-issued transfers proceed, which the protocol permits. What such a master gives up is the ability to stop the next access, and that is a design decision with real consequences: a processor that continues a burst into an unmapped region will take a second fault it could have avoided. Most CPU bus interfaces therefore do cancel. The distinction to hold is that this is an architectural choice recorded in the manager's specification, not a protocol conformance requirement.

The IDLE cancellation is concrete hardware: HTRANS is a master output (chapter on HTRANS), and IDLE is the encoding meaning "no transfer." A cancelling master presents HTRANS=IDLE before the capturing edge, so the address phase that would otherwise have launched the next transfer is recorded as IDLE instead. The master may then re-issue the intended transfer after handling the error, or abandon it.

The timing detail that makes this work — and the one worth being able to derive at a whiteboard — is that address and control are sampled on a rising HCLK edge only when HREADY is high. Holding HREADY low does not merely delay the data phase; it extends the address phase that overlaps it, leaving HTRANS uncommitted. That is why exactly one warning cycle is enough for exactly one pipeline stage, and why the mechanism needs no signal that does not already exist.

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. At the system level this is what lets a burst behave correctly under failure, for the managers that choose to abort. 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. Cancellation is an explicit master action (drive HTRANS=IDLE), not something the bus performs on the master's behalf, and the master is free not to take it. An automatic hardware abort would be simpler to reason about but would impose one recovery policy on every master. AHB provides the window and leaves the decision to the master — the same mechanism-versus-policy split as "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. This processor's bus interface is specified to abort a burst on error. It samples the warning at the edge ending this cycle, and presents HTRANS=IDLE for the next beat during the cycle that follows — before the capturing edge, so IDLE is what the bus records for that address phase. 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 and already captured — would have proceeded into the unmapped region, generating a second error. The processor would have had no chance to stop it even though its specification said to. The two-cycle response is what turns "abort the burst" from an intention into an implementable behaviour.
• A different, equally legal manager. A simple DMA engine on the same bus is specified to run its burst to completion and report the aggregate status afterwards. It sees the same two-cycle ERROR, leaves HTRANS alone, and issues the remaining beats — each of which also errors. That is not a protocol violation, and a bus monitor must not report it as one. It is a manager whose designers judged that a simpler interface was worth the extra failing beats.
• 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.

7b. Proving It — the Timing, the Checkers, and the Line Between Them

Everything above can be reduced to two questions a bench must answer: did the subordinate produce a legal two-cycle ERROR, and what did the manager do with the window. The first is a protocol assertion. The second is a coverage measurement, and only becomes an assertion when a project decides it should be.

The capturing edge — why one wait state is exactly enough

The whole mechanism turns on one AHB rule: address and control are captured on a rising HCLK edge only when HREADY is high. Follow the edges of an errored transfer T1 whose successor T2 has already been issued.

             cycle 0        cycle 1           cycle 2          cycle 3
             ---------      ---------------   --------------   ---------
HTRANS       NONSEQ (T2)    NONSEQ (T2)       IDLE  <-- new    ...
HADDR        A2             A2  (held)        A2               ...
HREADY       1              0                 1                1
HRESP        OKAY           ERROR             ERROR            OKAY
                            ^                 ^
                            |                 |
   edge ending cycle 1: the manager SAMPLES HRESP=ERROR with HREADY=0.
   It now knows. HREADY was low, so T2's address phase was NOT captured
   at this edge -- it is still open.
 
   edge ending cycle 2: HREADY is high, so THIS is the capturing edge for
   T2's address phase. Whatever HTRANS the manager presented during cycle 2
   is what the bus records. A manager that wants to cancel presents IDLE.

Read off the two facts that matter. The manager learns of the error one edge before the address phase is captured — that is the entire margin the protocol grants, and it is why the window is one cycle rather than two. And because HREADY was low at the learning edge, the address phase genuinely was still open; a single-cycle ERROR would have delivered the news and captured T2 at the same edge, leaving no margin at all.

The checker

Three properties belong to the protocol and hold against every conformant subordinate. The fourth is a policy check, kept separate on purpose.

// ahb_two_cycle_error_sva.sv
//
// Timing checks for the two-cycle ERROR response on an AHB-Lite subordinate.
// The full error-verification suite (sequences, scoreboard, coverage model)
// lives with the error-response-testing chapter; this module owns only the
// temporal shape of the response and the manager's use of the window.
//
// SCOPE: AHB-Lite / AHB5. HRESP is one bit: 0 = OKAY, 1 = ERROR.
module ahb_two_cycle_error_sva #(
  // Set to 1 only on an interface whose manager is SPECIFIED to abort on
  // error. Leaving it 0 is correct for a general protocol monitor.
  parameter bit MANAGER_CANCELS_ON_ERROR = 1'b0
) (
  input logic       HCLK,
  input logic       HRESETn,
  input logic       HREADY,     // global HREADY seen by the manager
  input logic       HRESP,      // 1 = ERROR
  input logic [1:0] HTRANS
);
  localparam logic [1:0] IDLE = 2'b00;
 
  // A completing ERROR cycle: HRESP high with HREADY high.
  let err_done = (HRESP === 1'b1) && (HREADY === 1'b1);
  // A first ERROR cycle: HRESP high with HREADY low.
  let err_warn = (HRESP === 1'b1) && (HREADY === 1'b0);
 
  // ---- PROTOCOL 1 (forward). A first ERROR cycle must be followed by a
  //      completing ERROR cycle. This catches a subordinate that abandons
  //      the sequence -- for example one that drops HRESP back to OKAY when
  //      it finally deasserts its wait state.
  a_error_completes: assert property (@(posedge HCLK) disable iff (!HRESETn)
    err_warn |=> err_done)
    else $error("first ERROR cycle was not followed by a completing ERROR cycle");
 
  // ---- PROTOCOL 2 (backward). A completing ERROR cycle must have been
  //      preceded by a first ERROR cycle.
  //
  //      This is the property that catches a ONE-CYCLE ERROR, and the forward
  //      property above cannot. A subordinate that asserts HRESP=ERROR for a
  //      single cycle with HREADY already high never creates the antecedent
  //      err_warn, so PROTOCOL 1 is vacuously true on every such transfer and
  //      the bug ships. Write both directions, always.
  a_error_not_one_cycle: assert property (@(posedge HCLK) disable iff (!HRESETn)
    err_done |-> $past(err_warn))
    else $error("ERROR completed in a single cycle -- no preceding warning cycle");
 
  // ---- PROTOCOL 3. The address phase must not move during the warning
  //      cycle other than by the manager's own choice of HTRANS. HADDR and
  //      the control signals are held while HREADY is low; that is a general
  //      wait-state rule, checked here on the interface this module sees.
  a_no_spurious_ready: assert property (@(posedge HCLK) disable iff (!HRESETn)
    err_warn |=> !$fell(HRESP) || HREADY)
    else $error("HRESP left ERROR before the response completed");
 
  // ---- POLICY, NOT PROTOCOL. Cancelling the already-issued transfer is
  //      permitted, not required: AMBA allows a manager to complete the
  //      remaining transfers of a burst after an ERROR. Enable this ONLY on
  //      an interface whose manager specification promises to abort, and
  //      report a failure as a policy violation, never a protocol one.
  if (MANAGER_CANCELS_ON_ERROR) begin : g_policy
    a_manager_cancels: assert property (@(posedge HCLK) disable iff (!HRESETn)
      err_warn |=> (HTRANS == IDLE))
      else $error("POLICY: manager did not cancel after ERROR (protocol permits this)");
  end
 
  // ---- MEASURE, do not judge. On a general monitor the manager's choice is
  //      something to observe, because a suite that has only ever seen one of
  //      the two behaviours has not tested the subordinate against the other.
  covergroup cg_error_window @(posedge HCLK);
    option.per_instance = 1;
    cp_manager_choice : coverpoint HTRANS iff (err_done && $past(err_warn)) {
      bins cancelled = {IDLE};
      bins continued = {[2'b01:2'b11]};
    }
  endgroup
  cg_error_window cg_inst = new();
endmodule

The coverpoint is the part most suites are missing. A subordinate is only proven against a continuing manager if some test actually continued, and bins continued sitting at zero hits after a full regression is the honest signal that it never did.

Error: ahb_monitor.a_master_cancels
  "manager did not cancel its pipelined transfer after ERROR"
  time 41_820 ns   HRESP=ERROR  HREADY=1  HTRANS=2'b11 (SEQ)

// BEFORE - a project policy stated as a protocol rule.
a_master_cancels: assert property (@(posedge HCLK) disable iff (!HRESETn)
  (HRESP == RSP_ERROR && !HREADYOUT) |=> (HTRANS == HTRANS_IDLE))
  else $error("manager did not cancel its pipelined transfer after ERROR");
 
// AFTER - scoped, labelled, and paired with a measurement.
//   1. Gated on a parameter set per interface, defaulting OFF.
//   2. The message says POLICY and names the specification that permits
//      the other behaviour, so the next reader does not re-file the bug.
//   3. A coverpoint records what the manager actually did either way.
if (MANAGER_CANCELS_ON_ERROR) begin : g_policy
  a_manager_cancels: assert property (@(posedge HCLK) disable iff (!HRESETn)
    (HRESP == RSP_ERROR && !HREADYOUT) |=> (HTRANS == HTRANS_IDLE))
    else $error("POLICY (not AMBA): manager %m did not cancel after ERROR; ",
                "AMBA permits completing the remaining burst transfers");
end

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 one cycle in which the already-issued address phase has not yet been captured — address and control are only sampled on a rising edge with HREADY high — so the master can still change HTRANS to IDLE and cancel it. Whether it does is the master's policy: AMBA permits cancelling the remaining beats of a burst and equally permits completing them. What the protocol requires is on the subordinate side — two cycles, HRESP held ERROR across both." The pipeline rationale, the sampling rule that makes the window real, and the discipline of separating the subordinate's obligation from the manager's option 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.
• A master that chooses to cancel does so by driving HTRANS to IDLE during the warning cycle — and must act in that cycle, because address and control are captured only on a rising edge with HREADY high.
• Cancelling is permitted, not required. AMBA allows a manager to complete the remaining transfers of a burst after an ERROR. Assert the subordinate's two-cycle shape as protocol; assert cancellation only as project policy.
• 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 a master that wants to stop the burst drive IDLE instead of launching the next failing beat. A subordinate must still handle a manager that continues.
• 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 exact temporal mechanism. The rest of the error cluster divides the subject deliberately, so it is worth knowing which page owns what:

• ERROR Response — what counts as an error and what the system does with it: the trigger taxonomy, the side-effect semantics, and the path from HRESP to a software fault.
• HRESP Generation — how a subordinate produces the response, including the RTL for the two-cycle sequence this page describes.
• Error Response Testing — how to verify error behaviour: sequences, scoreboard, and the full assertion suite.
• Master Response Handling — how a manager reacts across the response types.
• AHB-Lite Response Simplification — why AHB-Lite keeps only OKAY and ERROR.

For the timing rule that non-OKAY responses take two cycles, see Response Timing. For the pipeline that makes the window necessary, see The Two-Phase Pipeline and Address Phase Leads Data Phase. For the transfer type used to cancel, see IDLE Transfers. For the legacy responses that share the two-cycle shape but not its semantics, see RETRY Response and SPLIT Response. For the broader protocol map, see the AMBA family overview.

13. References

• Arm AMBA 5 AHB Protocol Specification (ARM IHI 0033) — the normative source for the ERROR response. It requires the two-cycle sequence from the subordinate, and it states the manager's cancellation of remaining burst transfers as a permission, explicitly allowing the manager to complete them instead. Read that paragraph before writing any assertion about HTRANS after an ERROR.
• Arm AMBA 3 AHB-Lite Protocol Specification (ARM IHI 0033A) — the single-bit HRESP definition assumed throughout this chapter.
• Arm AMBA 2 Specification — the two-bit HRESP encoding with RETRY and SPLIT, for readers maintaining legacy full-AHB systems. Those responses are out of scope here.
• IEEE 1800 (SystemVerilog) — concurrent assertions and the $past sampled-value function used by the backward property in section 7b; sequences and properties in the assertions clause.

Where this page describes conventions rather than requirements — that most CPU bus interfaces cancel, that policy checks should be labelled as such — it says so in the text. Everything stated as a protocol rule traces to the AMBA specification above.