RETRY Response

Chapters 7.1–7.2 covered the two responses every AHB version has — OKAY and ERROR. This chapter and the next cover two legacy responses that exist only in full AHB (AHB2) and were dropped in AHB-Lite and AHB5: RETRY and SPLIT. Both solve the same problem — a subordinate that will take a long time should not hold the bus the whole time — by freeing the bus instead of inserting wait states. RETRY is the simpler of the two: the subordinate cancels the transfer and tells the master to re-issue it later. The master keeps re-issuing the same transfer until the subordinate is finally ready and answers OKAY. RETRY frees the bus, but at the cost that the master polls by re-issuing — which is exactly the inefficiency SPLIT (chapter 7.4) was designed to fix.

1. What Is It?

RETRY is a full-AHB response (a two-cycle response, like ERROR) by which a subordinate that cannot complete a transfer soon cancels it — without completing it successfully — and signals the master to re-issue the exact same transfer later.

The flow is a loop: the master issues a transfer; the subordinate, unable to complete it promptly, returns RETRY; the transfer is cancelled and the bus is freed (the arbiter can grant it to other masters); the original master re-issues the same transfer later; and this repeats until the subordinate is finally ready and responds OKAY.

The defining feature of RETRY is that it frees the bus rather than holding it. Where a wait state (Module 6) keeps the transfer on the bus and stalls everyone until the subordinate finishes, RETRY cancels the transfer so other masters can use the bus during the (potentially long) wait. The price is that the original master must re-issue — it doesn't get notified when the subordinate is ready; it just keeps trying the same transfer until one attempt succeeds. So RETRY trades bus-holding for bus-freeing-plus-polling.

2. Why Does It Exist?

RETRY exists because wait states are a poor fit for long delays — holding the bus for many cycles stalls every other master — and full AHB (a multi-master bus) needed a way to let a slow subordinate step aside and free the bus for others.

Recall the wait-state cost (Module 6): a wait state holds the whole bus while one subordinate finishes (the shared-stall coupling). For a short delay (a few cycles), that is fine. But for a long delay — a subordinate that needs many cycles, or is waiting on something external — holding the bus the entire time would block every other master for a long stretch, wrecking system throughput in a multi-master system. So full AHB needed an alternative for long waits: a way for the slow subordinate to release the bus so other masters can make progress, and finish the slow transfer later. RETRY is that alternative — it frees the bus instead of holding it. It exists because long waits and a shared multi-master bus don't mix, and freeing the bus is better than hogging it.

The reason RETRY makes the master re-issue (rather than the subordinate notifying it) is simplicity — RETRY requires no extra signaling infrastructure. The subordinate just says "not now" (RETRY) and forgets about it; the master is responsible for trying again. There is no mechanism for the subordinate to track which master wanted what, or to signal readiness later. So RETRY is the simple bus-freeing response: minimal subordinate complexity, at the cost that the master polls (re-issues blindly). This simplicity is RETRY's reason for being the basic option — and its limitation is exactly the polling, which motivated SPLIT.

RETRY also exists as a distinct outcome the master must handle correctly: unlike a wait (where the master just holds and the same transfer completes), a RETRY means the transfer did not complete and must be re-issued. So the master's response to RETRY is fundamentally different from its response to a wait — cancel and re-issue, not hold and wait. RETRY exists partly to give the master this clear "your transfer didn't happen, do it again" signal, distinct from both success (OKAY), failure (ERROR), and delay (wait states). It is its own outcome in the response taxonomy.

3. Mental Model

Model RETRY as a busy clerk saying "I can't help you right now — please go to the back of the line and come back" — you step aside so others are served, then re-join and ask again, until the clerk can finally help.

You approach a clerk (the subordinate) with a request (a transfer). The clerk is swamped and says "I can't do this right now — step aside and try again later" (RETRY). So you leave the counter (the transfer is cancelled, the bus is freed) and other people get served (other masters use the bus). Then you come back and ask the same thing again (re-issue the same transfer). Maybe the clerk is still busy ("try again" — RETRY again), so you step aside once more. Eventually the clerk has time and helps you ("OKAY"). You kept re-asking (polling) because the clerk never called you back — it just told you to try again. That "no callback, keep asking" is RETRY's polling cost.

This captures RETRY: step aside so others are served = free the bus; come back and ask the same thing = re-issue the same transfer; keep re-asking until helped = poll until OKAY; no callback = the subordinate doesn't notify, the master must retry. The contrast with SPLIT (chapter 7.4) is a clerk who takes your number and calls you back when ready — no re-asking.

Watch the two-cycle RETRY response:

The model's lesson: RETRY is "try again later" — the transfer is cancelled and the master must re-ask, because the subordinate never calls back. In the waveform, the two-cycle RETRY (warning then cancellation) leaves the transfer not completed; the master re-issues. It looks like ERROR's timing but means "do it again," not "it failed."

4. Real Hardware Perspective

In hardware, RETRY is one of the four HRESP encodings in full AHB (OKAY/ERROR/RETRY/SPLIT, the 2-bit HRESP), driven by the subordinate as a two-cycle response, and it requires the master to hold the transfer's information so it can re-issue.

The subordinate produces RETRY exactly like ERROR — a two-cycle sequence: HRESP=RETRY with HREADY low (warning), then HRESP=RETRY with HREADY high (the transfer is cancelled). The two-cycle form gives the master a reaction window (chapter 7.6) — but unlike ERROR (where the master handles a failure), here the master must re-issue the transfer. So in hardware, the master needs to retain the transfer's address, control, and (for writes) data so it can re-present them. A master that issues RETRY-able transfers must be designed to re-issue — it can't discard the transfer on RETRY; it must keep it and try again. This is extra master complexity that RETRY imposes.

The bus-freeing is implemented through the arbiter (chapters 9.x): when a transfer gets RETRY, the master typically loses the grant (or the arbiter re-arbitrates), so other masters can use the bus. The original master must then re-arbitrate (request the bus again) to re-issue. So RETRY interacts with arbitration: cancelling the transfer and freeing the bus means the master goes back through the grant process to retry. This coupling to the arbiter is part of why RETRY (and SPLIT) only exist in full multi-master AHB — they are meaningless on a single-master bus (AHB-Lite), where there is no one else to free the bus for. This is a key reason AHB-Lite dropped them.

The distinction between RETRY and ERROR is purely in meaning, not timing — both are two-cycle responses with identical waveforms (just a different HRESP encoding). ERROR means "this transfer failed — handle the failure"; RETRY means "this transfer didn't complete — re-issue it." So the master's handler differs: ERROR → fault/exception handling; RETRY → re-issue the same transfer. The hardware must decode the HRESP value to tell them apart and route to the right handler. This is why HRESP needs more than one bit in full AHB — to distinguish ERROR, RETRY, and SPLIT, which share timing but mean different things.

A hardware note on why full AHB and not AHB-Lite: RETRY (and SPLIT) presume a multi-master bus with an arbiter — the whole point is freeing the bus for other masters. AHB-Lite is single-master (one master, no arbitration, chapter 14.x), so there is no other master to free the bus for, and RETRY/SPLIT have no purpose. Hence AHB-Lite (and AHB5's Lite-derived simplification) drop them, keeping only OKAY/ERROR. So RETRY is inherently a multi-master mechanism — its existence is tied to full AHB's shared-bus, arbitrated nature.

5. System Architecture Perspective

At the system level, RETRY is a multi-master fairness/throughput mechanism — it prevents a slow subordinate from monopolizing the shared bus during a long wait — but its polling inefficiency and its protocol complexity are why it (and SPLIT) were ultimately abandoned in favor of simpler buses and AXI.

RETRY's system purpose is bus throughput under contention: in a multi-master system, a subordinate that holds the bus for a long wait blocks every other master, serializing the system on the slowest access. RETRY breaks that by freeing the bus, so other masters make progress during the long wait. So RETRY is about keeping a busy multi-master bus flowing rather than letting one slow transfer stall it. This was a real concern in the multi-master AHB systems of its era, where several bus masters (CPU, DMA, etc.) contended for one bus and a slow peripheral could otherwise serialize everything.

The polling inefficiency is RETRY's architectural weakness: because the master re-issues blindly (no notification of readiness), the retries are wasted bus cycles — each re-issue that gets another RETRY accomplished nothing but consumed an arbitration and a transfer attempt. So RETRY trades one inefficiency (bus-holding) for another (wasted retries). In a system where the slow subordinate stays busy for a while, the master may RETRY many times, polling the bus repeatedly. This waste is exactly what SPLIT (chapter 7.4) addresses — by having the subordinate notify the arbiter when ready, eliminating the blind polling. So RETRY is the simpler-but-wasteful option, SPLIT the complex-but-efficient one.

The abandonment of RETRY (and SPLIT) in modern designs is the key architectural takeaway. Two trends killed them. First, AHB-Lite: most AHB usage shifted to the single-master AHB-Lite (simpler, no arbitration), where RETRY/SPLIT have no meaning — so they were dropped. Second, AXI: where true multi-master concurrency and outstanding-transaction handling were needed, the industry moved to AXI, whose independent channels and outstanding transactions handle slow subordinates far more efficiently than RETRY/SPLIT ever could (a slow subordinate's transaction is simply outstanding while others proceed, no polling). So RETRY/SPLIT were a transitional solution: a way to get some concurrency on a shared-bus protocol, superseded by AXI's natively-concurrent design. Understanding RETRY is partly understanding why AXI's model is better — RETRY's polling is precisely the problem AXI's outstanding transactions solve.

So RETRY's system story is: it solved a real multi-master-AHB throughput problem (don't let a slow slave hog the bus), did it simply but wastefully (polling), and was superseded — by AHB-Lite (which doesn't need it) and AXI (which does concurrency far better). It is important to understand (especially for legacy and interviews) but rare in new designs.

6. Engineering Tradeoffs

RETRY embodies the free-the-bus-simply tradeoff.

• RETRY (free the bus) vs wait states (hold the bus). RETRY frees the bus for other masters during a long wait, improving multi-master throughput, at the cost of re-issue (polling) overhead and added master complexity. Wait states hold the bus (simple, no re-issue) but stall everyone. The choice depends on delay length: waits for short delays, RETRY for long ones — though in practice both were largely superseded.
• RETRY (poll) vs SPLIT (notify). RETRY is simpler (subordinate just says "try again," no tracking) but wastes cycles polling. SPLIT is more complex (subordinate tracks the master and signals readiness via HSPLIT) but eliminates polling. RETRY trades efficiency for simplicity; SPLIT the reverse.
• Multi-master mechanism vs single-master simplicity. RETRY only makes sense on a multi-master arbitrated bus; it adds protocol complexity (extra HRESP encodings, arbiter coupling, master re-issue logic). AHB-Lite drops it entirely for single-master simplicity — a major reason AHB-Lite is the more popular variant.
• Shared-bus concurrency hack vs native concurrency (AXI). RETRY is a way to get some concurrency on a fundamentally shared, single-transfer bus. AXI provides native concurrency (independent channels, outstanding transactions) that handles slow subordinates without any polling. The industry largely chose AXI's native concurrency over AHB's RETRY/SPLIT hacks.

The throughline: RETRY frees the bus for a long wait, simply (the subordinate just says "try again") but wastefully (the master polls). Its costs — polling overhead, master re-issue logic, arbiter coupling, multi-master-only relevance, extra HRESP encodings — ultimately outweighed its benefit, leading to its removal in AHB-Lite/AHB5 and its supersession by AXI. It is a legacy mechanism worth understanding for context, rarely used in new designs.

7. Industry Example

Trace RETRY in a (legacy) multi-master full-AHB system.

A full-AHB system has two masters — a CPU and a DMA engine — sharing the bus, plus a slow peripheral that can be momentarily busy for a long time.

• The CPU hits the busy peripheral. The CPU issues a read to the slow peripheral, which is busy for a long time. Rather than insert dozens of wait states (stalling the DMA the whole time), the peripheral returns RETRY: cancel the read, free the bus.
• The DMA gets the bus. With the CPU's transfer cancelled and the bus freed, the arbiter grants the bus to the DMA, which makes progress on its transfers during the peripheral's busy period. The slow peripheral did not block the DMA — RETRY freed the bus for it. This is the throughput benefit.
• The CPU re-issues (polls). The CPU, having received RETRY, re-arbitrates for the bus and re-issues the same read to the peripheral. If the peripheral is still busy, it returns RETRY again, and the CPU steps aside once more. The CPU keeps re-issuing — polling — because the peripheral never notifies it of readiness.
• Eventually OKAY. When the peripheral is finally free, the CPU's re-issued read gets OKAY with valid data. The transaction completes — after several wasted retry attempts. The polling worked, but those retries were overhead.
• What SPLIT would do better. Had the peripheral used SPLIT (chapter 7.4) instead, it would have remembered the CPU and signaled the arbiter (via HSPLIT) exactly when ready, so the CPU would be re-granted only when the data was available — no blind polling, no wasted retries. SPLIT trades complexity for eliminating RETRY's polling waste.
• What a modern design does. A modern system would avoid this entirely: use AHB-Lite and bridge the slow peripheral to APB (isolating its delays), or use AXI where the peripheral's transaction is simply outstanding while the CPU and DMA proceed — no RETRY, no polling. RETRY is the legacy answer to a problem now solved more cleanly.

The example shows RETRY's value (freeing the bus so the DMA runs during the CPU's long wait) and its cost (the CPU polling with wasted retries until the peripheral was ready). It also frames RETRY in history: a reasonable mechanism for multi-master AHB, improved by SPLIT, and superseded by AHB-Lite (avoidance) and AXI (native concurrency).

8. Common Mistakes

9. Interview Insight

RETRY is a legacy-knowledge interview topic — it tests whether you understand AHB's history and the bus-freeing mechanisms.

The answer that lands frames RETRY by purpose and history: "RETRY is a legacy full-AHB response — a two-cycle response, same timing as ERROR but meaning 'try again.' A slow subordinate that can't complete soon returns RETRY: the transfer is cancelled, the bus is freed for other masters, and the original master must re-issue the same transfer later, repeating until it gets OKAY. The point is to free the bus during a long wait instead of stalling everyone with wait states. Its weakness is that the master polls — it re-issues blindly because the subordinate doesn't notify it of readiness. SPLIT fixes that by having the subordinate signal the arbiter when ready. Both are full-AHB only — AHB-Lite and AHB5 drop them, keeping just OKAY and ERROR — and AXI's outstanding transactions ultimately superseded the whole idea." The purpose (free the bus for long waits), the polling weakness, and the legacy/history framing are the senior signals.

10. Practice Challenge

Reason from RETRY's mechanism and place in history.

1. Describe the loop. Walk through the RETRY flow from issue to eventual OKAY.
2. Contrast with a wait. Explain how RETRY differs from a wait state and when each is appropriate.
3. Explain the polling. Why does the master poll on RETRY, and what is the cost?
4. Version scope. State which AHB versions have RETRY and why the others drop it.
5. Historical placement. Explain how SPLIT and then AXI improved on RETRY.

11. Key Takeaways

• RETRY is a legacy full-AHB two-cycle response (same timing as ERROR, different meaning) by which a slow subordinate cancels the transfer and frees the bus.
• The master must re-issue the same transfer later, repeating until it gets OKAY — it retains the address/control/data to do so.
• RETRY frees the bus for other masters during a long wait (vs a wait state that holds the bus), improving multi-master throughput.
• The cost is polling — the master re-issues blindly because the subordinate gives no readiness notification; retries that hit RETRY again are wasted cycles.
• RETRY (and SPLIT) exist only in full AHB — AHB-Lite and AHB5 drop them, keeping only OKAY/ERROR, because they are multi-master-only mechanisms.
• RETRY was superseded — by SPLIT (which adds notification, removing polling), by AHB-Lite (single-master, no need), and ultimately by AXI (outstanding transactions). Legacy knowledge, rarely used in new designs.

12. What Comes Next

You now understand RETRY. The next chapter covers its more sophisticated sibling:

• 7.4 — SPLIT Response (coming next) — how SPLIT improves on RETRY by having the subordinate remember the master and signal the arbiter (via HSPLIT) when ready, eliminating the polling — at the cost of significant complexity.

To revisit the responses, see OKAY Response and ERROR Response. For the wait-state alternative RETRY improves on for long delays, see Slave-Inserted Wait States. For why AXI superseded this approach, see AXI vs AHB vs APB. For the broader protocol map, see the AMBA family overview.