Single Transfer vs Burst Transfer

The pipeline chapter showed how AHB streams transfers efficiently. This chapter introduces the construct that makes streaming explicit and optimal: the burst. A burst is a run of related transfers — a cache line, a DMA block — that the manager declares up front and streams under a single bus grant, with the subordinate knowing the beats are coming. We will contrast a single transfer with a burst, meet the burst shapes (SINGLE, INCR, WRAP) at the conceptual level, and see why bursts are how AHB sustains real bandwidth. As always at this stage, we name the shapes and their purpose but leave the bit-level HBURST encodings to Module 3.

1. What Is It?

A single transfer is one beat: one address phase, one data phase, complete in itself. A burst transfer is a sequence of related beats that the manager announces as a unit and streams consecutively, typically with addresses that step in a regular pattern.

The defining difference is declaration and continuity. With single transfers, each access is independent — the bus does not know another related access is coming. With a burst, the manager says "this is a 4-beat incrementing burst" at the start, so the bus and the subordinate know the whole shape in advance. That foreknowledge is what lets a burst be efficient: arbitration is won once for the whole convoy, the addresses follow a known pattern, and the subordinate can prepare for the beats it knows are coming.

2. Why Does It Exist?

Bursts exist because bulk data movement is the common case, and single transfers waste effort on it.

Consider what a single transfer costs beyond the data itself: the manager may need to win arbitration for the bus, present a fresh address, and the subordinate must treat it as an isolated event. For a one-off access — poking a configuration register — that overhead is fine; it happens rarely. But for moving a cache line, a DMA block, or a frame of pixels, you are doing many related accesses to consecutive addresses, and paying that per-access overhead on every beat is pure waste. The accesses are not really independent — they are one logical operation ("move these 64 bytes") chopped into beats.

The burst recognizes that logical operation and lets you express it directly. By declaring "a burst of N beats in this pattern," the manager:

• Amortizes arbitration: it wins the bus for the whole burst rather than re-arbitrating per beat, so other masters do not interleave mid-convoy and the grant overhead is paid once.
• Makes addresses implicit: the beats follow a known pattern (incrementing, wrapping), so the address is predictable rather than freshly computed and re-presented as an unrelated value each time.
• Lets the subordinate optimize: a memory that knows a 4-beat incrementing burst is coming can prefetch or open the right row ahead of the later beats, instead of being surprised by each one.

So bursts exist to match the bus's behaviour to the reality of the traffic: most high-bandwidth movement is sequential and bulk, and a burst is the construct that says so, unlocking efficiencies that isolated transfers cannot. Without bursts, a high-performance bus would spend much of its effort on per-access ceremony instead of moving data.

3. Mental Model

Model the difference as mailing letters one at a time versus shipping a labelled pallet.

A single transfer is mailing one letter: address it, take it to the post office, send it. Fine for the occasional letter. A burst is shipping a pallet: you declare "this pallet has 4 boxes going to consecutive bays," hand it over once, and the carrier moves the whole pallet under one booking, knowing the layout in advance. You do not re-book and re-address for each box; the pallet is one operation with a known shape.

Now watch a real 4-beat incrementing burst at signal level — the canonical picture for this chapter:

The model's takeaway is the signature: a burst is one NONSEQ beat (the start) followed by SEQ beats (continuations) with the address stepping in the burst's pattern. See NONSEQ-then-SEQ with an incrementing address, and you are looking at a burst streaming under one grant. The transfer-type codes themselves are detailed in Module 3; here, recognize the shape.

4. Real Hardware Perspective

In hardware, a burst rides on the same two-phase pipeline you already know — it is not a separate mechanism. Each beat of the burst is an ordinary address-phase-then-data-phase transfer; what makes it a burst is that the manager keeps the bus, marks the beats as continuations, and steps the address.

So a burst is, mechanically, a pipelined stream of beats where the manager does not release the bus between them and signals (via the transfer type) that each beat after the first is a sequential continuation of the same burst. The subordinate, seeing the burst declared, can use the known length and pattern to prepare. The address for each beat follows the burst's rule — increment by the beat size for an incrementing burst, or wrap at a boundary for a wrapping burst — which means the manager's address generation is a simple counter rather than fresh arbitrary addresses.

The wrap behaviour is the one piece of real hardware cleverness worth noting. A wrapping burst increments the address but wraps back to an aligned boundary partway through, so the beats stay within an aligned block (a cache line). This exists because of how caches fill: when a processor misses on a particular word, the memory system can deliver that word first and then wrap around to fill the rest of the line, so the processor gets the data it is stalled on as early as possible. The wrap pattern is hardware shaped precisely around the cache-line-fill access pattern — a beautiful example of the protocol matching real silicon behaviour.

Because a burst is just the pipeline with a held grant and continuation marking, it inherits all the pipeline's properties: it streams one beat per cycle when HREADY stays high, and it stalls (bubbles) on wait states or a mid-burst pause. A burst does not escape the shared-bus, one-access-path-at-a-time reality — it is the most efficient use of it, not an exception to it.

5. System Architecture Perspective

At the system level, bursts are how an AHB subsystem extracts its real bandwidth, and they are the natural unit in which high-traffic masters think.

A DMA engine moving a block does not think in single accesses — it thinks in bursts: "move this region as a sequence of incrementing bursts." A processor cache fills and evicts lines as wrapping or incrementing bursts. So the masters that generate the bulk of an AHB's traffic are inherently burst-oriented, and the burst is the construct that lets them express their bulk operations efficiently to the bus. A system designed without bursts would force these masters to issue floods of single transfers, drowning in per-access overhead and re-arbitration — the architecture would leave most of its bandwidth on the table.

Bursts also interact with arbitration at the system level, and this is a genuine design tension. Because a burst holds the bus for its whole length, a long burst gives the granting master excellent throughput but makes other masters wait longer for the bus — exactly the throughput-versus-latency arbitration tradeoff from the components chapter, now driven by burst length. Systems with latency-sensitive masters often bound burst length (or let the arbiter break very long bursts) so that no single burst monopolizes the bus beyond the latency budget of the others. So the choice of burst lengths is a system-level knob balancing streaming efficiency against worst-case access latency for everyone else.

Finally, bursts connect to the memory subsystem's efficiency. Memories — especially external DRAM behind a controller, but even on-chip memories — are far more efficient at sequential, burst access than at scattered single accesses. A burst's declared, patterned addresses let the memory controller open rows, prefetch, and pipeline its own internal operations. So bursts are not just a bus efficiency; they are how the bus presents traffic to memory in the shape memory wants. The whole path — master to bus to memory — is most efficient when bulk data moves as bursts, which is why bursts are central to any high-performance AHB subsystem.

6. Engineering Tradeoffs

Bursts are powerful, and using them well is a matter of balancing their benefits against their costs.

• Streaming efficiency vs arbitration latency for others. A longer burst amortizes arbitration over more beats and sustains higher throughput for the granting master — but it holds the bus longer, increasing the worst-case wait for every other master. The tradeoff is one master's bandwidth versus others' latency, tuned by bounding burst length.
• Foreknowledge vs flexibility. Declaring a burst up front lets the subordinate optimize, but commits the manager to the declared shape. Fixed-length bursts give the subordinate the most foreknowledge (it knows exactly how many beats) but less flexibility; an unspecified-length incrementing burst is flexible (the manager can end it when done) but gives the subordinate less to plan around. The tradeoff is optimization potential versus adaptability.
• Burst alignment and wrap vs simplicity. Wrapping bursts serve cache-line fills beautifully (critical word first, stay within the line) but add address-wrap logic and alignment rules. Incrementing bursts are simpler but do not give the critical-word-first benefit. The tradeoff is access-pattern fit versus address-generation simplicity.
• Bulk efficiency vs single-access overhead. Bursts are the right tool for bulk movement but bring no benefit — and a little conceptual overhead — for genuinely one-off accesses. A single register write should be a single transfer; wrapping it in burst machinery would be pointless. The tradeoff is recognizing which traffic is bulk (burst it) and which is incidental (single transfer).

The through-line: bursts trade a longer bus hold and up-front commitment for amortized overhead and subordinate optimization. They are the right choice for the bulk, sequential traffic that dominates a high-performance bus's bandwidth, and the wrong choice for incidental single accesses. Matching the construct to the traffic — burst the convoys, single-transfer the one-offs — is the practical skill.

7. Industry Example

Contrast two real operations on an AHB: a register poke and a DMA block move.

A register write (single transfer). Firmware sets a peripheral's control register. This is one isolated 32-bit write to one address — there is no convoy, nothing sequential coming. It is a single transfer: one address phase presenting the register address, one data phase moving the value, done. Wrapping this in burst machinery would be pointless; the single transfer is exactly right for incidental, one-off access. This is the traffic that, on a real chip, lives behind the APB bridge anyway — small, occasional, no bandwidth concern.

A DMA block move (bursts). A DMA engine copies a 256-byte buffer between on-chip memories. It does not issue 64 independent single transfers — it issues a sequence of incrementing bursts (say, several 4- or 8-beat bursts). Each burst wins the bus once and streams its beats one per cycle with addresses incrementing, the source and destination memories prefetching and pipelining because they know the pattern. The DMA sustains near-peak bandwidth, and the per-access overhead that would have dominated 64 single transfers is amortized across the bursts. This is AHB doing what it is for: moving bulk data efficiently.

A cache-line fill (wrapping burst). A processor misses in its cache on a particular word. The memory system uses a wrapping burst: it delivers the missed (critical) word first, then wraps around the aligned line to fill the rest. The processor gets the word it stalled on as early as possible and can resume, while the rest of the line fills behind it. The wrap pattern is shaped exactly for this, and it is why wrapping bursts exist.

The arbitration tension, live. Now suppose the DMA's bursts are very long while the processor needs a latency-sensitive fetch. The processor's fetch waits behind the DMA's burst — and if the burst is too long, the processor stalls beyond its budget. The system bounds the DMA's burst length so its streaming efficiency does not starve the processor. Every one of these decisions — single vs burst, burst shape, burst length — follows directly from matching the construct to the traffic and balancing efficiency against latency, which is the engineering content of this chapter.

8. Common Mistakes

9. Interview Insight

Bursts are common interview material because they test whether you understand why a construct exists, not just that it does.

The answer that lands explains the why and the limit: "A burst declares a run of related beats up front — first beat NONSEQ, the rest SEQ, addresses stepping in a pattern — and streams them under a single grant. That amortizes arbitration over the whole convoy and lets the subordinate prefetch because it knows the pattern, so bursts sustain real bandwidth. Single transfers are for one-off accesses. But a burst is still pipelined, one beat at a time on one shared bus — it's efficient streaming, not concurrency." The streaming-not-concurrency point, again, is the senior signal.

10. Practice Challenge

Reason from the burst signature and the efficiency-versus-latency tradeoff.

1. Spot the signature. Describe the transfer-type and address pattern that identifies a 4-beat incrementing burst on a waveform. Check against Figure 2.
2. Justify the win. In three sentences, explain why one 8-beat burst moves data more efficiently than eight single transfers.
3. Choose the construct. For (a) a control-register write and (b) a 1 KB DMA copy, say whether you would use single transfers or bursts, and why.
4. Explain WRAP. Describe the access pattern WRAP is built for and why critical-word-first matters.
5. Resolve the tension. A long DMA burst is starving a latency-sensitive master. Explain the mechanism and the fix in terms of burst length and arbitration.

11. Key Takeaways

• A single transfer is one beat; a burst is a declared run of related beats streamed under one grant with addresses in a regular pattern.
• A burst's power is foreknowledge and amortization: arbitration is paid once, addresses are implicit, and the subordinate can optimize because it knows the beats and pattern are coming.
• The signature is NONSEQ then SEQ with a stepping address — recognizable on any waveform. (HBURST encodings are Module 3.)
• Burst shapes fit access patterns: INCR for general sequential movement, WRAP for cache-line fills with critical-word-first. WRAP is purpose-built, not arbitrary.
• A burst is the pipeline made explicit, not a new engine — it streams one beat per cycle, stalls on wait states, and holds the bus for its length (an arbitration/latency tradeoff that bounds burst length).
• A burst is efficient streaming, not concurrency — still one access path at a time on one shared bus. Match the construct to the traffic: burst the convoys, single-transfer the one-offs.

12. What Comes Next

You now understand how AHB moves both isolated accesses and bulk data. One chapter remains in this module — the widely used single-master simplification of the protocol:

• 2.7 — AHB-Lite Overview (coming soon) — the single-master AHB-Lite subset, what it drops from full AHB, and why it dominates real designs.

To revisit the pipeline that bursts ride on and the phases that compose each beat, see Pipelined Operation, The Address / Control Phase, and The Data Phase. For the arbitration tradeoff bursts intensify, see Master, Slave, Decoder & Arbiter. For the broader protocol map, see the AMBA family overview.