AMBA AHB · Module 8

SINGLE Transfers

The AHB SINGLE transfer — the degenerate one-beat 'burst' (HBURST=SINGLE) for isolated, non-sequential accesses like register reads and writes — and why every transfer declares an HBURST value even when it isn't a burst.

Chapter 8.1 introduced bursts and the eight HBURST encodings. This chapter covers the simplest one: SINGLE — the degenerate "burst" of length one. A SINGLE transfer is a single NONSEQ beat with no SEQ beats following; HBURST=SINGLE. It exists because every AHB transfer declares an HBURST value, so there must be a value meaning "not a burst" — and SINGLE is it. SINGLE is used for isolated, non-sequential accesses: a single register read or write, a control-register access, any one-off transfer where there's no block of sequential data to move. It is the access pattern of control-plane traffic, as opposed to the burst-based data-plane traffic of caches and DMA. Short and foundational, this chapter rounds out the burst taxonomy by covering its trivial base case.

1. What Is It?

A SINGLE transfer is a one-beat burst: HBURST=SINGLE, consisting of a single NONSEQ transfer with no SEQ beats following. It is the degenerate burst of length one — a transfer that is not part of a multi-beat sequence.

Figure 1 — a SINGLE transfer is a burst of length one: HBURST=SINGLE, a single NONSEQ beat with no SEQ beats following. It's still an HBURST value because every AHB transfer declares an HBURST type — so there must be a value meaning 'not a burst.' SINGLE is that value, for an isolated, non-sequential transfer with no pattern to declare.

The key facts: SINGLE has exactly one beat (NONSEQ — a new transfer), and that's the whole "burst." There's no address pattern to follow (no increment, no wrap) because there's only one beat. HBURST=SINGLE is the value the manager drives for any transfer that isn't part of a multi-beat burst. So SINGLE is, in effect, the "no burst" declaration — every transfer must declare some HBURST value, and SINGLE is the one that says "this is just one isolated transfer."

2. Why Does It Exist?

SINGLE exists because not all accesses are blocks — many are isolated, one-off transfers — and the protocol needs a way to express "this is just one transfer, not a burst" within the uniform burst framework where every transfer declares an HBURST value.

Many real accesses are genuinely isolated: reading a single status register, writing a single control register, a one-word access to a scattered location. These have no sequential block to move, so a multi-beat burst would be meaningless (there's nothing to follow the first beat). The protocol needs to express these isolated accesses — and since the burst framework requires every transfer to declare an HBURST type, there must be a type meaning "just one transfer." SINGLE is that type. So SINGLE exists to express the common, legitimate case of an isolated access within the burst framework — it's how you say "not a burst" when HBURST must say something.

The reason it's framed as a one-beat burst (rather than a separate "non-burst" concept) is uniformity: by making SINGLE one of the HBURST values, the protocol treats bursts and non-bursts with the same signals and structure — every transfer declares HBURST, marks HTRANS, and so on. There's no separate mechanism for non-burst transfers; a SINGLE is just a burst of length one. So the uniformity comes from folding the non-burst case into the burst framework as the degenerate length-one burst. This is cleaner than having two separate concepts (burst vs non-burst): it's all bursts, and SINGLE is the trivial one. The protocol is simpler for treating SINGLE uniformly with the multi-beat types.

The reason SINGLE has no address pattern is simply that there's nothing to pattern — with one beat, there's no second address to compute, so no increment or wrap applies. So SINGLE is distinguished from INCR/WRAP by having no pattern (because it has no subsequent beats), and from the fixed-length types by having length one. It's the simplest possible burst: one beat, NONSEQ, done. SINGLE exists as this trivial base case, completing the taxonomy so that every transfer — block or isolated — fits the burst framework.

3. Mental Model

Model SINGLE versus a burst as buying a single item at a checkout versus doing a full grocery run — sometimes you just need one thing, and "one item" is still a valid (if trivial) shopping trip.

A full grocery run (a burst) is a planned sequence — you have a list, you move through the aisles systematically, the trip is worth the overhead. But sometimes you just need one thing — a carton of milk (a single register access). You still go to the store and check out (you still issue a transfer), but there's no list, no sequence — it's a one-item trip (SINGLE). It would be silly to treat a one-item purchase as a "shopping run with a list of one"; you just grab it and go. Yet in the store's eyes, it's still a valid trip — just the trivial case. You wouldn't plan a full grocery run to buy one carton of milk (don't use a burst for an isolated access), and you wouldn't buy a week's groceries one item at a time (don't use SINGLE for block movement) — match the trip to the need.

This captures SINGLE: a one-item trip = a single isolated transfer; still a valid trip = SINGLE is still an HBURST value (the trivial one); no list/sequence = no address pattern; match the trip to the need = use SINGLE for isolated accesses, bursts for blocks. The one-item trip is legitimate and common — just trivial.

Watch a SINGLE transfer:

A SINGLE transfer (one NONSEQ beat)

3 cycles

Figure 2 — a SINGLE transfer. HBURST=SINGLE and HTRANS=NONSEQ for the one beat at address A. There are no SEQ beats — after this single transfer, the next transfer (if any) is unrelated, starting its own NONSEQ. The single beat completes (HREADY high) and that's the whole 'burst.' Contrast the back-to-back SEQ beats of a multi-beat burst (Figure 3 of chapter 8.1).

The model's lesson: SINGLE is the one-item trip — a single isolated transfer, the trivial burst. In the waveform, there's one NONSEQ beat with HBURST=SINGLE and no SEQ beats following. It's a complete, valid transfer — just not part of a sequence. Use it when you genuinely need only one access.

4. Real Hardware Perspective

In hardware, a SINGLE transfer is just a normal transfer with HBURST driven to SINGLE and HTRANS=NONSEQ — there's no special "single" mechanism; it's the absence of burst continuation (no SEQ beats).

The manager drives HBURST=SINGLE and issues one NONSEQ transfer. There are no subsequent SEQ beats, so the manager's address generator doesn't compute a pattern — it just presents the one address. So a SINGLE is hardware-trivially the simplest transfer: one beat, no burst-continuation logic engaged. The subordinate sees HBURST=SINGLE and knows not to expect SEQ beats following — there's no burst to track. So both sides handle SINGLE as the no-continuation case: the manager doesn't generate a pattern, the subordinate doesn't track a burst.

For the subordinate and memory controller, HBURST=SINGLE is information too: it tells them no sequential block is coming, so they shouldn't prefetch ahead (unlike a burst, where they'd prefetch). So SINGLE signals "isolated access — don't optimize for a sequence." This is the flip side of bursts signaling intent (chapter 8.1): a burst says "prefetch the pattern," SINGLE says "no pattern, just this one." So a memory controller treats a SINGLE as a one-off (open row, access, done) rather than setting up for a stream. The HBURST=SINGLE declaration is useful precisely because it tells the memory not to expect more.

A hardware note on why every transfer carries HBURST: even an isolated transfer drives HBURST (=SINGLE), because the address-phase control group is uniform — every transfer presents HADDR, HTRANS, HSIZE, HWRITE, and HBURST. There's no "burst mode" that's separately enabled; HBURST is always present, and SINGLE is its default-ish value for non-burst transfers. So in hardware, HBURST is a standard part of every transfer's address phase, and SINGLE is simply the value that says "length one." This uniformity means burst and non-burst transfers use identical signaling — only the HBURST value (and the presence/absence of SEQ beats) differs.

A subtle hardware point: a sequence of SINGLE transfers to sequential addresses is not the same as a burst, even though the addresses might increment. Each SINGLE is independent (NONSEQ, HBURST=SINGLE), so the memory sees them as unrelated one-off accesses and doesn't prefetch — losing the burst efficiency. So issuing back-to-back SINGLEs to sequential addresses is a mistake (it should be a burst): the addresses increment, but without the burst declaration, the memory can't optimize. This is why using the right HBURST matters (chapter 8.1's "match the type to the pattern"): sequential block movement should be a burst, not a series of SINGLEs, even though both touch the same addresses.

5. System Architecture Perspective

At the system level, SINGLE transfers are the control-plane access pattern — isolated register and control accesses — as distinct from the burst-based data-plane traffic, and recognizing this distinction guides how a system's traffic is structured.

SINGLE accesses dominate control-plane traffic: configuring peripherals, reading status registers, writing control registers, polling — all isolated, one-off accesses with no sequential block. So the control plane (the CPU managing the system's peripherals and state) is largely SINGLE traffic. These accesses are typically latency-sensitive (a quick register read/write) rather than bandwidth-sensitive, and they're isolated by nature. So SINGLE is the right pattern for the control plane: isolated, low-bandwidth, latency-oriented accesses. The system's control traffic is SINGLE-dominated.

The data plane, by contrast, is burst-dominated (chapter 8.1): cache fills, DMA, bulk streams — high-bandwidth sequential block movement using INCR/WRAP bursts. So the system's traffic splits along this line: control-plane = SINGLE (isolated, latency-oriented), data-plane = bursts (sequential, bandwidth-oriented). This split guides architecture: bandwidth-critical paths (memory, DMA) are optimized for bursts, while control paths (peripheral registers) handle SINGLEs. Often the slow control-plane peripherals are even on a different bus (APB, via a bridge — chapter 1.4), precisely because their SINGLE, low-bandwidth traffic doesn't need the high-performance AHB data path. So the SINGLE-vs-burst distinction maps onto the system's control-vs-data-plane structure and even its bus topology.

Figure 3 — when to use SINGLE versus a burst. Use SINGLE for isolated, non-sequential accesses — a single register read/write, a control/status/config access, any one-off transfer with no sequential block — the control-plane pattern. Use a burst for block movement — cache line fills (WRAP), DMA/buffer copies (INCR), bulk streams — the data-plane pattern. Match the transfer type to the access pattern.

The architectural takeaway is using the right pattern for the right traffic: SINGLE for isolated control accesses (don't burst a register read), bursts for sequential data movement (don't SINGLE a block copy). Mismatching wastes efficiency — bursting an isolated access adds no benefit (there's no block), and SINGLE-ing a block loses the burst's amortization and prefetch (chapter 8.1). So an architect (and a programmer/driver writer) matches the access pattern to the transfer type: SINGLE for one-off accesses, bursts for blocks. This matching is part of writing efficient drivers and designing efficient datapaths — recognizing which traffic is control-plane (SINGLE) and which is data-plane (burst), and using the right transfer type for each. SINGLE is the correct, efficient choice for its domain (isolated accesses); it's only a mistake when misapplied to block movement.

6. Engineering Tradeoffs

SINGLE embodies the express-the-isolated-case-uniformly choice.

SINGLE as a burst type vs a separate non-burst concept. Folding the isolated case into the burst framework as a length-one burst keeps the signaling uniform (every transfer declares HBURST) at the trivial cost of a "burst" that isn't really one. A separate non-burst mechanism would duplicate signaling. AHB folds it in — uniformity is cleaner.
SINGLE for isolated accesses vs always bursting. Using SINGLE for genuinely isolated accesses is correct and efficient (no burst overhead for one access). Forcing a burst on an isolated access would be pointless (no block to amortize over). SINGLE is the right tool for one-off accesses.
SINGLEs vs a burst for sequential blocks. A series of SINGLEs to sequential addresses works but loses burst efficiency (no amortization, no prefetch). A burst is the right choice for sequential blocks. So SINGLE is correct for isolated accesses but a mistake for block movement — the tradeoff is using the right pattern.
Latency vs bandwidth orientation. SINGLE suits latency-sensitive isolated accesses (control plane); bursts suit bandwidth-sensitive sequential movement (data plane). The transfer type matches the traffic's orientation.

The throughline: SINGLE is the degenerate one-beat burst that expresses isolated, non-sequential accesses uniformly within the burst framework. It's the correct, efficient choice for control-plane traffic (register/control accesses) and a mistake only when misapplied to sequential block movement (which should use a burst). The design folds the non-burst case into the burst taxonomy for signaling uniformity — every transfer is a "burst," and SINGLE is the trivial one.

Don't move a sequential block as a series of SINGLEs — use a burst

The one practical pitfall with SINGLE: don't use a series of SINGLE transfers to move a sequential block — use a burst. It's tempting (and easy) to issue back-to-back single-word accesses to consecutive addresses, but even though the addresses increment, each SINGLE is an independent transfer the memory sees as unrelated — so it can't prefetch, can't amortize the row-open, and you lose all the burst efficiency (chapter 8.1). The result is far lower bandwidth than a burst would achieve for the same data. So whenever you're moving a sequential block (copying a buffer, filling a structure, streaming data), use the appropriate burst (INCR for linear, WRAP for cache-line-aligned) — not a loop of SINGLEs. Reserve SINGLE for genuinely isolated accesses (a single register, a one-off word). This is a common efficiency bug in drivers and DMA setups: SINGLE-ing a block that should be bursted. Match the transfer type to the access pattern — SINGLE for one-off, burst for blocks.

7. Industry Example

Trace SINGLE transfers in their natural habitat — the control plane.

A CPU manages a system's peripherals while also moving bulk data, using the right transfer type for each.

Peripheral configuration — SINGLE writes. At startup, the CPU configures peripherals by writing their control registers — each a single, isolated write (SINGLE). Setting a UART's baud rate, enabling a timer, configuring a GPIO direction: all one-off SINGLE writes to scattered register addresses. There's no sequential block — each is an independent control access. SINGLE is correct.
Status polling — SINGLE reads. The CPU polls a peripheral's status register, repeatedly reading one register (SINGLE reads). Each read is isolated (the same single address, no sequence). SINGLE is the right pattern — there's no block to burst.
A one-word data access — SINGLE. The CPU reads a single configuration word from memory — an isolated access. SINGLE. No block, no burst.
A cache line fill — WRAP burst (not SINGLE). The CPU misses on a load and fills a cache line — a sequential block, so it uses a WRAP burst (chapter 8.1), not a series of SINGLEs. Using SINGLEs here would lose the burst efficiency. The data-plane access correctly uses a burst.
A DMA copy — INCR burst (not SINGLEs). The DMA engine copies a buffer using INCR bursts, not back-to-back SINGLEs. Again, the data-plane block movement uses bursts.
The control-vs-data split. The CPU's control traffic (register config, status polling) is SINGLE; its data traffic (cache fills) and the DMA's traffic (copies) are bursts. The system naturally splits: isolated control accesses use SINGLE, sequential data movement uses bursts. A well-written driver respects this — SINGLE for registers, bursts for blocks. Using SINGLEs for the DMA copy, or bursts for register writes, would be wrong (inefficient or pointless respectively).

The example shows SINGLE in its proper role: the control plane (peripheral configuration, status polling, isolated accesses), distinct from the burst-based data plane (cache fills, DMA). SINGLE is the correct, efficient choice for isolated accesses, and the system uses it precisely there — reserving bursts for sequential block movement. The right transfer type for the right traffic.

8. Common Mistakes

SINGLE-transfer misconceptions

"SINGLE isn't a burst type." It is — SINGLE is one of the eight HBURST encodings, the degenerate length-one 'burst.' Every transfer declares an HBURST value, and SINGLE is the non-burst one.
"A series of SINGLEs to sequential addresses is a burst." No — each SINGLE is independent (the memory sees unrelated accesses, can't prefetch). Sequential block movement should be a burst, not a series of SINGLEs.
"SINGLE has SEQ beats." No — SINGLE is one NONSEQ beat with no SEQ beats. SEQ beats are what continue a multi-beat burst; SINGLE has none.
"You should burst everything for efficiency." No — burst blocks, but use SINGLE for genuinely isolated accesses (register reads/writes). Bursting an isolated access adds no benefit.
"SINGLE and IDLE are the same." No — SINGLE is a real transfer (HBURST=SINGLE, HTRANS=NONSEQ) that moves data; IDLE (HTRANS=IDLE) is no transfer. Different things.
"SINGLE is rarely used." No — SINGLE dominates control-plane traffic (register/control accesses), which is very common. It's the right pattern for a large class of accesses.

9. Interview Insight

SINGLE is a quick interview check — it tests whether you understand the burst taxonomy completely (including its base case) and the control-vs-data-plane distinction.

Figure 4 — a strong answer in one card: SINGLE (HBURST=SINGLE) is a one-beat burst — a single NONSEQ transfer with no SEQ beats — the HBURST value meaning not-a-burst, used for isolated non-sequential accesses like register reads/writes; every transfer declares an HBURST, so SINGLE covers the non-burst case uniformly. The senior point: SINGLE is the control-plane access pattern while INCR/WRAP bursts are the data-plane pattern, and using SINGLE for block movement wastes burst efficiency.

The answer that lands places SINGLE in the taxonomy and its use: "SINGLE is the degenerate one-beat burst — HBURST=SINGLE, a single NONSEQ transfer with no SEQ beats. It's still an HBURST encoding because every AHB transfer declares an HBURST value, so there has to be one meaning 'not a burst' — that's SINGLE. You use it for isolated, non-sequential accesses: a single register read or write, a control access, any one-off transfer where there's no sequential block to move. It's essentially the control-plane access pattern — configuring peripherals, polling status — as opposed to the burst-based data-plane pattern of cache fills and DMA. The one thing to avoid is using a series of SINGLEs to move a sequential block: that loses the burst's amortization and prefetch, so block movement should always use a burst." The taxonomy placement, the control-vs-data-plane framing, and the don't-SINGLE-a-block pitfall are the senior signals.

🔍 The discriminator: SINGLE is the control-plane pattern, and SINGLE-ing a block is the efficiency bug

The discriminator on SINGLE is whether you connect it to the control-vs-data-plane distinction and the common efficiency bug. A weak answer says "SINGLE is one transfer." A strong answer adds: SINGLE is the control-plane access pattern — isolated, latency-oriented register and control accesses — distinct from the burst-based data-plane (cache fills, DMA, bulk streams). This framing shows you understand when SINGLE is right (isolated control accesses) versus when bursts are (sequential data). The key practical insight — and a real-world bug — is that moving a sequential block as a series of SINGLEs loses all the burst efficiency (no amortization, no prefetch), even though the addresses increment; sequential block movement must use a burst, not a SINGLE loop. A candidate who frames SINGLE as the correct choice for its domain (control-plane isolated accesses), explains it's the 'not a burst' HBURST value that keeps signaling uniform, and flags the SINGLE-ing-a-block efficiency bug demonstrates they understand the burst taxonomy completely and know how to use transfer types efficiently — more than just defining SINGLE. That practical, full-taxonomy understanding is the senior signal even on this simple topic.

10. Practice Challenge

Reason from the SINGLE base case.

Define SINGLE. Explain what a SINGLE transfer is and how it's marked (HBURST, HTRANS).
Explain the framing. Why is SINGLE a 'burst' type rather than a separate concept?
Read the waveform. From Figure 2, identify what makes this a SINGLE rather than a burst.
Choose the type. Given a register write and a buffer copy, state which uses SINGLE and which uses a burst, and why.
The pitfall. Explain why moving a block as a series of SINGLEs is inefficient.

11. Key Takeaways

SINGLE is a one-beat burst — HBURST=SINGLE, a single NONSEQ transfer with no SEQ beats. The degenerate base case of the burst taxonomy.
It's the 'not a burst' HBURST value — every transfer declares an HBURST type, and SINGLE is the one for isolated, non-sequential accesses.
Folding it into the burst framework keeps signaling uniform — bursts and non-bursts use identical address-phase signals; SINGLE is just length one.
SINGLE is the control-plane access pattern — register reads/writes, control/status accesses, one-off transfers — distinct from the burst-based data plane (cache fills, DMA).
It signals 'no sequence coming' to the memory (don't prefetch) — the flip side of a burst's prefetch hint.
Don't move a sequential block as a series of SINGLEs — that loses the burst's amortization and prefetch; block movement should always use a burst. Match the transfer type to the access pattern.

12. What Comes Next

You now understand the burst taxonomy's base case. The next chapters cover the multi-beat types:

8.3 — INCR (Undefined-Length) Bursts (coming next) — unbounded incrementing bursts and how they terminate.
8.4 onward (coming soon) — the fixed-length INCR4/8/16 and the WRAP types.

To revisit the burst concept and types, see Burst Overview. For the NONSEQ beat that a SINGLE uses, see NONSEQ Transfers; contrast with IDLE Transfers (no transfer). For the HBURST signal, see HBURST. For the broader protocol map, see the AMBA family overview.