BUSY Transfers

This chapter examines BUSY, the subtlest of the four transfer types and the one most often misunderstood. BUSY lets a master pause inside a burst when it cannot present the next beat yet — without abandoning the burst. It is easy to confuse with IDLE (which is not inside a burst) and with a wait state (which is the subordinate not ready, not the master). Getting BUSY right is what lets a master fed by an imperfect data source — a FIFO that occasionally runs dry — sustain efficient bursts. We cover how BUSY works, why the burst stays alive, the three-way BUSY/IDLE/wait-state distinction, and when to use BUSY versus IDLE. This builds on the overview (4.1), IDLE (4.2), and the HTRANS encoding (3.3).

1. What Is It?

BUSY (HTRANS = 01) means the master is inside a burst but not ready to present the next beat yet. It is a non-transfer (like IDLE, no access happens this cycle), but unlike IDLE it keeps the burst alive: the master remains committed to the burst, holds the address of the upcoming beat, and will resume with SEQ when it is ready.

Its defining properties:

• It is only valid inside a burst — you cannot use BUSY for a single transfer or when not in a burst (that is IDLE).
• The burst stays committed — BUSY signals "I am still doing this burst, just pausing," not "abandon it."
• The address points at the next (upcoming) beat — the master holds the address it will use when it resumes.
• The subordinate performs no access for the BUSY beat but keeps the burst context alive, knowing more SEQ beats are coming.

The essence: BUSY is the master saying "still in the burst, just not ready for the next beat." It is the mechanism that lets a master pause mid-burst without paying the cost of abandoning and restarting it. The contrast that defines BUSY is with its two look-alikes: IDLE (a non-transfer outside a burst) and a wait state (the subordinate not ready, signalled by HREADY low). BUSY is uniquely "the master not ready, inside a burst."

2. Why Does It Exist?

BUSY exists because masters are often fed by imperfect data sources that cannot always supply the next burst beat exactly on time — and abandoning the burst when that happens would be wasteful.

Consider a master mid-burst — a DMA engine writing a block, fed by a FIFO. The burst is streaming beats efficiently, but the FIFO momentarily runs dry: the master has no data for the next beat this cycle. It has three conceptual options:

• Drive garbage — present a beat with invalid data. Unacceptable; it corrupts the transfer.
• Abandon the burst — end it (drive IDLE) and start a new burst later. This works but is wasteful: it throws away the arbitration won for the burst and the burst setup the subordinate used to optimize (chapter 2.6), and forces a re-start.
• Pause without abandoning — signal "I'm still doing this burst, just not ready for the next beat right now." This is BUSY, and it is the right answer.

BUSY exists to provide that third option. By driving BUSY, the master rides out the gap — the burst stays committed, the subordinate keeps its burst context (no re-setup needed), and when the data arrives the master resumes with SEQ exactly where it left off. So BUSY exists to let a master tolerate momentary gaps in its data supply without sacrificing burst efficiency. It is the protocol's accommodation of the reality that real data sources (FIFOs, bridges, anything with variable timing) do not always have the next beat ready.

The reason BUSY is distinct from IDLE — rather than reusing IDLE for mid-burst pauses — is that the subordinate needs to know whether the burst is continuing or ending. IDLE means "not in a burst" (the burst, if any, is over); BUSY means "still in the burst." A subordinate tracking a burst for optimization must treat these differently: on BUSY it keeps the burst context (more beats coming); on IDLE it does not. So the two non-transfer types exist precisely because "paused mid-burst" and "not in a burst" are different situations the subordinate must distinguish.

3. Mental Model

Model BUSY as a runner in a relay pausing at the baton exchange without leaving the race.

In a relay (a burst), a runner is mid-race. Suddenly they are not quite ready for the next leg — but they do not step off the track (that would be IDLE, leaving the race). Instead they hold their position, baton in hand, signalling "still racing, just not moving this instant" (BUSY). The race officials (the subordinate) know the runner is still in the race — they keep the lane reserved and expect them to continue. When the runner is ready, they resume the next leg (SEQ). Stepping off the track (IDLE) would mean the race is over and they would have to re-enter from the start; pausing in place (BUSY) keeps them in the race.

Watch a burst with a BUSY pause:

The model's lesson: BUSY is pausing in place without leaving the race — the burst stays alive, the address is held at the next beat, and HREADY stays high (the master is pausing, not the subordinate stalling). Note in the waveform that HREADY never drops: that is the visual tell that BUSY is a master pause, distinct from a subordinate wait state.

4. Real Hardware Perspective

In hardware, BUSY is a master output driven on HTRANS, and the key behaviours are the address hold, the burst-context preservation, and the distinction from a wait state.

A master drives BUSY on HTRANS when, mid-burst, it cannot present the next beat. While driving BUSY, it holds the address of the upcoming beat — the beat it will perform when it resumes — so the burst's address sequence is preserved. The subordinate, seeing BUSY, performs no access for that beat (it is a non-transfer) but maintains its burst context: it knows the burst is continuing and more SEQ beats are coming, so it does not tear down any burst-specific preparation (prefetch state, an open memory row). When the master resumes with SEQ, the subordinate continues the burst seamlessly.

The three-way distinction is the crux, and it is the most-tested point:

• BUSY — the master is not ready, and it is inside a burst. Driven on HTRANS. The burst stays alive. HREADY can stay high (the master is pausing, not the subordinate).
• IDLE — the master has nothing to do, and it is not in a burst. Driven on HTRANS. No burst context.
• Wait state — the subordinate is not ready. Signalled by HREADY low, on any transfer type. Extends the data phase.

The two axes that separate them: who is not ready (master for BUSY/IDLE; subordinate for a wait state) and whether a burst is in progress (BUSY is in a burst; IDLE is not). Confusing BUSY with a wait state (thinking they are the same "pause") is a classic error — they are driven by different sides on different signals (HTRANS = BUSY is master-side; HREADY low is subordinate-side). In hardware, a master generates BUSY from its own not-ready condition (e.g., FIFO empty) on HTRANS, while a wait state comes from the subordinate on HREADY.

A subtle hardware point: there are usually limits on BUSY in a burst. A master should not drive BUSY indefinitely (that would stall the burst forever), and for fixed-length bursts BUSY cannot replace a required beat — it only delays beats. The master must eventually present the real beats. So BUSY is a bounded pause, used for momentary gaps, not a way to permanently stall a burst.

5. System Architecture Perspective

At the system level, BUSY is what lets imperfect, real-world masters use efficient bursts, and it preserves the burst-based performance the memory subsystem depends on.

Real masters that generate bursts — DMA engines, bridges, streaming interfaces — are frequently fed by buffers (FIFOs) whose fill level varies with upstream timing. Without BUSY, any momentary buffer underrun mid-burst would force the master to either stall the whole bus (bad) or abandon the burst and restart (wasteful, and it defeats the memory's burst optimization). BUSY lets these masters ride out underruns within the burst, so they can keep using long, efficient bursts despite imperfect data supply. So BUSY is the system-level accommodation that makes burst-based performance robust to real timing variation — it is why a DMA fed by a sometimes-empty FIFO can still stream efficiently.

BUSY also preserves the memory subsystem's optimization. Recall that memories optimize for bursts by anticipating the declared pattern (prefetching, keeping rows open). If a master abandoned a burst on every underrun (using IDLE), the memory would lose its burst context and have to re-establish it on the restart — repeatedly throwing away the optimization. BUSY keeps the burst context alive across the pause, so the memory's prefetch and row state survive, and the burst resumes efficiently. So BUSY is not just convenient for the master; it protects the system-wide efficiency of burst access by keeping the subordinate's burst optimization intact through pauses.

The system-level relationship to wait states matters too: BUSY (master-side pause) and wait states (subordinate-side pause) are the two ways a burst can be slowed, from the two ends. A system analyzing burst throughput must attribute pauses correctly — BUSY cycles to the master's data supply (fix: deeper FIFO, faster upstream), wait states to the subordinate's speed (fix: faster subordinate, or bridge it). Conflating them misdirects optimization. So at the system level, the BUSY/wait-state distinction is also a diagnostic one: it tells you which end of a burst is the bottleneck.

So BUSY's system role is to make burst-based performance robust to real masters' imperfect data supply, to preserve the memory's burst optimization through pauses, and to provide (with wait states) a two-ended view of where a burst's pauses come from.

6. Engineering Tradeoffs

BUSY's design reflects choices about pausing without abandoning.

• Pause-without-abandon (BUSY) vs abandon-and-restart. BUSY lets a master pause mid-burst cheaply (the burst and the subordinate's optimization survive), at the cost of a dedicated transfer type and the rules around it. The alternative — abandon the burst and restart — wastes arbitration and burst setup. BUSY trades a little protocol complexity for robust, efficient bursts from imperfect sources; a clear win.
• Distinct BUSY vs reusing IDLE. Having BUSY separate from IDLE lets the subordinate distinguish "paused in a burst" from "not in a burst," preserving burst context across pauses, at the cost of a fourth transfer type. Reusing IDLE would be simpler but would force the subordinate to abandon burst context on every pause. The distinct type is worth it for burst preservation.
• Bounded BUSY vs unlimited. BUSY is meant for momentary gaps, not indefinite stalls; a master holding BUSY forever would freeze the burst. The (implicit) bound keeps BUSY a brief pause, trading the freedom to pause indefinitely for the guarantee that bursts make progress. A master that genuinely cannot supply data for a long time should not be using BUSY to wait — it should structure its transfers differently.
• Master-side pause (BUSY) vs subordinate-side (wait state). Having two pause mechanisms — one per side — lets each side independently signal "not ready," which is necessary (the master and subordinate have independent timing). The cost is the conceptual overhead of two mechanisms, but they are genuinely different situations (master data supply vs subordinate speed), so two mechanisms are appropriate.

The throughline: BUSY trades a dedicated transfer type and a bounded-pause discipline for the ability to pause a burst without abandoning it — preserving burst efficiency and the subordinate's optimization through momentary data-supply gaps. It is the protocol's accommodation of imperfect masters, and the distinction from IDLE and wait states is what makes it work correctly.

7. Industry Example

Trace a DMA burst that hits a FIFO underrun, handled correctly with BUSY and incorrectly with IDLE.

A DMA engine streams a block to memory as an incrementing burst, fed by an internal FIFO.

• The burst streams (NONSEQ, SEQ…). The DMA opens the burst with NONSEQ and continues with SEQ beats, the FIFO supplying data each cycle. The memory, having seen the burst declared, prefetches and streams efficiently.
• The FIFO underruns mid-burst. Upstream timing causes the FIFO to momentarily empty — the DMA has no data for the next beat this cycle.
• Handled correctly (BUSY). The DMA drives BUSY, holding the next beat's address. The burst stays committed; the memory keeps its burst context (prefetch and row state intact) and waits, no access for the BUSY beat. HREADY stays high (the subordinate is not stalling). When the FIFO refills, the DMA resumes with SEQ at the held address and completes the burst. The underrun cost only the BUSY cycles; the burst's efficiency and the memory's optimization survived intact.
• Handled incorrectly (IDLE). Suppose instead the DMA drove IDLE on the underrun. The memory sees IDLE (not in a burst), concludes the burst is over, and tears down its burst context. When the FIFO refills, the DMA must start a new burst with NONSEQ — re-winning arbitration and forcing the memory to re-establish burst setup. The single underrun turned one efficient burst into two, with the overhead of a restart and lost memory optimization. Repeated underruns would shred throughput into many short, restarted bursts.
• The diagnostic view. On a capture, the correct case shows NONSEQ, SEQ…, BUSY, SEQ… — one burst with a pause. The buggy case shows NONSEQ, SEQ…, IDLE, NONSEQ, SEQ… — two bursts, the IDLE-then-NONSEQ revealing the abandon-and-restart. An engineer reading the HTRANS track would immediately see the difference.

The contrast shows BUSY's purpose: it lets a real, FIFO-fed DMA tolerate underruns without abandoning bursts, preserving efficiency. Using IDLE instead is the classic bug that turns one burst into many.

8. Common Mistakes

9. Interview Insight

BUSY is a favourite because the three-way distinction reveals real protocol understanding.

The answer that lands gives BUSY's behaviour and the three-way distinction: "BUSY is the master pausing inside a burst when it can't present the next beat — it keeps the burst alive, holds the next beat's address, and the subordinate performs no access for the BUSY beat but keeps its burst context. BUSY is only valid inside a burst; you use IDLE when not in a burst. And critically, BUSY is the master not ready (driven on HTRANS), distinct from a wait state, which is the subordinate not ready (HREADY low). Use BUSY, not IDLE, to pause a burst — IDLE would abandon it." The master-vs-subordinate distinction and the BUSY-keeps-burst rule are the senior signals.

10. Practice Challenge

Reason from the three-way distinction and the burst-preservation purpose.

1. Define BUSY. State what BUSY means and the four key properties (in-burst-only, burst stays alive, address held, no access).
2. Three-way distinction. Distinguish BUSY, IDLE, and a wait state by who is not ready and which signal carries each.
3. Read the waveform. In Figure 2, identify the BUSY cycle, what the address does, and why HREADY stays high.
4. Choose correctly. A DMA's FIFO underruns mid-burst. State which transfer type to drive and why the alternative is wrong.
5. Diagnose restarts. A master's bursts keep restarting under data pressure. Explain how IDLE-instead-of-BUSY causes it and the fix.

11. Key Takeaways

• BUSY (01) is the master pausing inside a burst — it keeps the burst alive, holds the next beat's address, and the subordinate performs no access for the BUSY beat but keeps the burst context.
• BUSY is only valid inside a burst — use IDLE when not in a burst. BUSY keeps the burst; IDLE ends it.
• BUSY exists to let imperfect masters pause without abandoning a burst — a FIFO-fed DMA can ride out underruns and keep using efficient bursts.
• The three-way distinction: BUSY (master not ready, in a burst, HTRANS), IDLE (master nothing to do, not in a burst, HTRANS), wait state (subordinate not ready, HREADY low). Two axes: who is not ready, and whether a burst is in progress.
• HREADY typically stays high during BUSY (master pause) — the visual tell distinguishing it from a wait state (HREADY low).
• The classic bug is IDLE-instead-of-BUSY — it abandons the burst, forcing costly restarts that shred throughput. Use BUSY to pause a burst.

12. What Comes Next

You now understand both non-transfer types. The next chapters cover the real transfers that carry the burst's beats:

• 4.4 — NONSEQ Transfers (coming next) — the first beat of a burst or a single transfer.
• 4.5 — SEQ Transfers (coming soon) — the continuation beats of a burst.

To revisit the type system and IDLE that BUSY contrasts with, see Transfer Types Overview and IDLE Transfers; for the burst structure BUSY pauses and the wait states it is distinct from, see Single Transfer vs Burst Transfer and The Data Phase. For the broader protocol map, see the AMBA family overview.