Burst Overview

This opens Module 8 — Burst Transfers, the mechanism that defines AHB's efficient data movement. So far, transfers have been considered individually. A burst groups a sequence of related transfers — called beats — into one unit, signalled by HBURST. Instead of issuing N independent transfers (each re-establishing context), the manager declares "this is a 4-beat incrementing burst" once, and the beats stream back-to-back with a known address pattern. This buys two things: it amortizes the address-phase and arbitration overhead over many beats, and it signals intent so memory can optimize (prefetch the coming beats). This first chapter introduces the burst concept, the eight HBURST encodings, the NONSEQ/SEQ beat structure, and why bursts matter — it is the Critical foundation for the whole module.

1. What Is It?

A burst is a sequence of related transfers — beats — issued as one unit, with the burst type declared on HBURST (a 3-bit signal). The beats follow a known address pattern and stream back-to-back.

The eight HBURST encodings are:

• SINGLE — a single beat (no burst; chapter 8.2).
• INCR — an unspecified-length incrementing burst (increments each beat; length not fixed, ends when the manager stops).
• INCR4 / INCR8 / INCR16 — fixed-length incrementing bursts of 4, 8, or 16 beats.
• WRAP4 / WRAP8 / WRAP16 — fixed-length wrapping bursts of 4, 8, or 16 beats that wrap at an aligned boundary (for cache line fills).

Each transfer in a burst is a beat, and the beats are marked by HTRANS: the first beat is NONSEQ (a new, non-sequential transfer), and the subsequent beats are SEQ (sequential — following the burst's address pattern). So a 4-beat burst is NONSEQ, SEQ, SEQ, SEQ. The two families differ in the address pattern: INCR increments linearly (each beat's address is the previous plus the beat size), while WRAP increments but wraps at an aligned boundary (so a cache line fill stays within the line). The fixed-length types (4/8/16) declare the beat count up front; INCR (plain) is open-ended.

2. Why Does It Exist?

Bursts exist because moving a block of data as N independent transfers is wasteful — each independent transfer re-establishes context and may re-arbitrate, and the memory can't anticipate the pattern. A burst eliminates that waste by declaring the whole block as one intent.

Consider moving a 4-word block as four separate single transfers. Each re-presents its address and control, each may have to re-arbitrate for the bus (in multi-master systems), and gaps can open between them — overhead repeated four times. Worse, the memory sees four unrelated accesses and can't optimize: it doesn't know a sequential block is coming, so it can't prefetch. A burst fixes both: the manager declares "4-beat incrementing burst" once, the beats stream back-to-back (amortizing the per-transfer overhead), and the memory knows the pattern (so it can prefetch the coming beats). So bursts exist to make block data movement efficient — amortizing overhead and enabling memory optimization that independent transfers cannot.

The signal-intent purpose is as important as the amortization. By declaring the burst type (especially the address pattern), the manager tells memory what's coming: an INCR4 says "four sequential words from here," a WRAP4 says "a cache-line's worth wrapping at this boundary." Memory controllers use this to prefetch — open the row, fetch ahead, pipeline internally — turning a burst into far more than four isolated accesses. So bursts exist partly to communicate access patterns to memory, which is essential for high memory bandwidth. A burst isn't just "transfers without gaps"; it's a declaration of intent that memory optimizes against.

The WRAP types exist specifically for cache line fills — a key access pattern. When a CPU cache misses on a word, it fetches the whole cache line, but it wants the missed word first (critical-word-first), then the rest of the line, wrapping at the line boundary. WRAP bursts express exactly this: start at the missed word, increment, and wrap around at the aligned line boundary so the whole line is fetched in the order the cache wants. So WRAP exists to serve the cache-line-fill pattern efficiently — a major reason bursts have a wrapping variant. INCR serves linear streaming (DMA, sequential copies); WRAP serves cache fills. The two patterns cover the dominant block-movement use cases.

3. Mental Model

Model a burst as ordering "the usual four-course meal" at a restaurant instead of ordering each course separately — one order communicates the whole sequence, the kitchen prepares ahead, and the courses come out smoothly in order.

If you order each course separately (four single transfers), you flag the waiter four times, each time explaining what you want, and the kitchen handles four unrelated requests with gaps between — it can't prepare ahead because it doesn't know what's next. But if you order "the four-course tasting menu" (a 4-beat burst), one order communicates the whole sequence: the kitchen knows all four courses are coming, in order, so it prepares ahead (starts the next course while you eat the current), and the courses flow smoothly back-to-back. The single declaration (the menu type — like HBURST) tells the kitchen the whole plan. And there are different "menus": a linear sequence of courses (INCR — just proceed in order) versus a fixed tasting menu that cycles through a set (WRAP — a bounded, structured set).

This captures bursts: ordering the whole menu at once = declaring the burst (HBURST) rather than N separate transfers; the kitchen preparing ahead = memory prefetching on the declared intent; courses flowing back-to-back = beats streaming without re-setup; different menu types = INCR (linear) vs WRAP (bounded/structured for cache lines). One declaration of the whole sequence beats N separate requests — that's the burst's value.

Watch a 4-beat incrementing burst:

The model's lesson: one declaration (HBURST) communicates the whole sequence, so beats stream back-to-back with a known pattern. In the waveform, HBURST=INCR4 declares the burst; HTRANS goes NONSEQ then SEQ×3; HADDR increments predictably. The manager ordered "the four-course menu" once, and the beats flow.

4. Real Hardware Perspective

In hardware, the burst is carried by HBURST (3 bits, declared with the address phase of each beat) alongside the HTRANS NONSEQ/SEQ marking, and the address increments are computed by the manager following the declared pattern.

HBURST is a 3-bit address-phase signal, presented with each beat's address (like HSIZE/HWRITE). It's typically held constant across the burst (all beats declare the same HBURST). So a subordinate (and the memory controller) reads HBURST to know the burst type and length, which it uses to anticipate the beats. The 3 bits encode the eight types (SINGLE/INCR/INCR4/INCR8/INCR16/WRAP4/WRAP8/WRAP16). In hardware, HBURST is just another control signal in the address-phase group, carrying the burst declaration.

HTRANS distinguishes the beats: NONSEQ for the first beat (a new transfer starting the burst), SEQ for the subsequent beats (continuing the established pattern). So the subordinate uses HTRANS to know "this is the burst's start" (NONSEQ) versus "this is a continuation following the known pattern" (SEQ). The SEQ marking is what tells the subordinate the address follows the burst's pattern (increment or wrap), so it can anticipate. In hardware, the manager drives NONSEQ then SEQ across the burst's beats, and the subordinate reads HTRANS to track the burst's progress. (BUSY can also appear mid-burst to pause it — chapter 8.11.)

The address generation is the manager's job: it computes each beat's HADDR by following the declared pattern. For INCR, each beat's address is the previous plus the beat size (HSIZE). For WRAP, the manager increments but wraps the address at the aligned boundary (the boundary determined by the burst length × beat size). So the manager has address-increment logic that knows the pattern from HBURST. This is concrete hardware: an address generator that, given the start address, the size, and the burst type, produces the sequence. The subordinate can also predict the addresses (for prefetch) by the same logic, since the pattern is fully determined by HBURST/HSIZE/start-address.

A hardware note on alignment and boundaries: WRAP bursts wrap at an aligned boundary so the burst stays within a naturally-aligned block (e.g., a WRAP4 of words wraps within a 16-byte-aligned block). This alignment is what makes WRAP suitable for cache lines (which are aligned). INCR bursts, by contrast, just increment and can cross such boundaries (though there are rules about not crossing certain boundaries that later chapters and AXI detail). So the address generation respects the burst type's boundary rules — WRAP stays within its aligned block, INCR increments linearly. This boundary behavior is part of what each burst type means in hardware.

5. System Architecture Perspective

At the system level, bursts are the mechanism for high-bandwidth data movement — they are how DMA engines, cache fills, and bulk transfers achieve throughput, and the HBURST intent declaration is what lets memory controllers run efficiently.

Bursts are essential for memory bandwidth. A modern memory (especially DRAM, but also pipelined SRAM) is far more efficient at sequential access than random access — opening a row, then streaming words from it. A burst declares exactly this sequential pattern, letting the memory controller open the row once and stream the beats, achieving near-peak bandwidth. Without bursts (N random single transfers), the memory would pay the row-open overhead repeatedly, crippling throughput. So bursts are the bridge between the bus and efficient memory access — they communicate the sequential intent that memory needs to run fast. High-bandwidth subsystems (graphics, DMA, CPU caches) depend on bursts.

The major burst users map to the burst types. DMA engines use INCR bursts (often unspecified-length INCR) to stream blocks of data — linear copies, buffer transfers. CPU caches use WRAP bursts for line fills — fetching a cache line, critical-word-first, wrapping at the line boundary. Bulk peripheral transfers (e.g., a display controller reading a framebuffer) use long INCR bursts. So the burst types serve the system's main bulk-movers: INCR for linear streaming, WRAP for cache fills. An architect choosing burst types matches them to the access pattern — INCR for sequential blocks, WRAP for aligned cache-line-sized fills.

The intent declaration has system-wide value beyond one transfer: because a burst tells the whole path (interconnect, memory controller) what's coming, the entire datapath can optimize — the interconnect can keep the path established for the burst's duration, the memory controller can prefetch, buffers can be sized to the burst. So a burst optimizes the whole datapath, not just the bus segment. This is why bursts are central to system performance: they're a coordination mechanism that aligns the manager, interconnect, and memory around a known data-movement pattern. The more the system knows about the access pattern (via the burst declaration), the more it can optimize — which is the core value of bursts at the architectural level. (This intent-declaration idea is taken even further in AXI, with its richer burst and outstanding-transaction model.)

6. Engineering Tradeoffs

Bursts embody the amortize-and-declare-intent design.

• Bursts vs independent transfers. Bursts amortize per-transfer overhead and declare intent (memory prefetch) at the cost of some complexity (burst-aware managers and subordinates, address generation). Independent transfers are simpler but waste overhead and can't signal patterns. For block movement, bursts win decisively — the efficiency gain is large.
• Fixed-length (4/8/16) vs unspecified (INCR). Fixed-length bursts declare the count up front (memory knows exactly how many beats — best for prefetch) but require knowing the length in advance. Unspecified INCR is flexible (stream until done) but the memory knows less (open-ended). Both exist: fixed for known-size blocks (cache lines), INCR for variable streams (DMA).
• WRAP vs INCR. WRAP serves cache fills (wrap at the aligned boundary, critical-word-first) but is constrained to aligned blocks. INCR serves linear streaming but doesn't wrap. The two cover the dominant patterns; choosing the wrong one (e.g., INCR for a cache fill) loses the wrapping benefit.
• Burst length vs flexibility/latency. Longer bursts amortize overhead more (higher throughput) but commit the bus/path for longer and can increase latency for other masters (the burst holds the resource). Shorter bursts are more responsive but amortize less. The length is tuned to balance throughput and latency.

The throughline: bursts amortize per-transfer overhead over many beats and declare access intent so memory can optimize — the foundation of AHB's efficient data movement. The cost is burst-aware logic (address generation, NONSEQ/SEQ handling) and reduced responsiveness during long bursts. The benefit — high memory bandwidth via amortization and prefetch — is essential for any data-moving system, which is why bursts are Critical and central to AHB's performance.

7. Industry Example

Trace bursts across the major data-movers in a system.

A SoC has a CPU with caches, a DMA engine, and a display controller, all moving data over AHB to memory.

• CPU cache line fill — WRAP burst. The CPU misses on a load. The cache fetches the whole line, issuing a WRAP burst (e.g., WRAP8 for an 8-beat line) starting at the missed word, incrementing and wrapping at the line boundary — critical-word-first, then the rest of the line. The memory controller, seeing WRAP8, fetches the aligned line efficiently. The CPU gets the critical word first (resuming sooner) and the line fills behind it. WRAP served the cache pattern exactly.
• DMA block copy — INCR burst. The DMA engine copies a buffer. It issues a long INCR burst (unspecified length, or INCR16 chunks), streaming sequential words. The memory controller, seeing the incrementing pattern, opens the row and streams — near-peak bandwidth. The DMA moves the block far faster than N single transfers would. INCR served the linear streaming pattern.
• Display framebuffer read — long INCR. The display controller reads the framebuffer sequentially each frame, using long INCR bursts. The sustained sequential access, declared as bursts, lets the memory deliver the high bandwidth a display needs. Again, INCR for linear bulk movement.
• An isolated register access — SINGLE. The CPU reads a single status register — an isolated, non-sequential access. It uses SINGLE (chapter 8.2) — no burst, because there's no block to move. Using a burst here would be pointless. SINGLE for the genuinely isolated case.
• The bandwidth picture. The system's memory bandwidth is dominated by the burst traffic (cache fills, DMA, display) — all using bursts to declare sequential intent and let the memory run efficiently. The SINGLE accesses (register reads) are a small fraction. So the system's performance rests on bursts: they're how the bulk data moves at speed. Remove bursts (force all single transfers) and memory bandwidth would collapse.

The example shows bursts as the backbone of data movement: WRAP for cache fills (critical-word-first, aligned), INCR for DMA and display (linear streaming), and SINGLE only for isolated accesses. Each burst type matches its access pattern, and the memory controller optimizes against the declared intent. The system's bandwidth lives in the burst traffic — which is why bursts are central to AHB performance.

8. Common Mistakes

9. Interview Insight

Bursts are a Critical, frequently-asked interview topic — explaining why bursts exist (amortize + signal intent) and the INCR-vs-WRAP distinction shows real understanding.

The answer that lands covers the concept, the types, and the why: "A burst is a sequence of related transfers — beats — issued as one unit, with HBURST declaring the type. There are eight encodings: SINGLE for a single beat, INCR for an unspecified-length incrementing burst, the fixed-length INCR4/8/16 (incrementing) and WRAP4/8/16 (wrapping). The first beat is NONSEQ, the rest are SEQ. INCR increments linearly — good for DMA and linear streaming — while WRAP increments but wraps at an aligned boundary, which serves cache line fills (critical-word-first, staying within the line). The reason bursts matter is two-fold: they amortize the address-phase and arbitration overhead over many beats, and — just as importantly — they signal intent, telling the memory controller the access pattern so it can prefetch. That's why bursts are the foundation of high-bandwidth data movement in AHB." The eight types, the INCR-vs-WRAP distinction with use cases, and the amortize-plus-signal-intent rationale are the senior signals.

10. Practice Challenge

Reason from the burst concept.

1. Define a burst. Explain what a burst is and how its beats are marked (HTRANS).
2. List the types. Name the eight HBURST encodings and group them (single / incrementing / wrapping).
3. Read the waveform. From Figure 3, identify the burst type, the beats, and the address pattern.
4. INCR vs WRAP. Explain the difference and give a use case for each.
5. The deeper why. Explain why declaring access intent (not just amortizing overhead) is the key benefit of bursts.

11. Key Takeaways

• A burst is a sequence of related beats issued as one unit, with HBURST declaring the type; the beats stream back-to-back with a known address pattern.
• Eight HBURST encodings: SINGLE (1 beat), INCR (unspecified-length incrementing), INCR4/8/16 (fixed-length incrementing), WRAP4/8/16 (fixed-length wrapping).
• The first beat is NONSEQ, the rest are SEQ (HTRANS) — marking the burst's start and continuation.
• INCR increments linearly (DMA, sequential streaming); WRAP wraps at an aligned boundary (cache line fills, critical-word-first).
• Bursts amortize the address-phase and arbitration overhead over many beats — efficiency over independent transfers.
• Crucially, bursts signal intent — declaring the access pattern so the memory controller can prefetch and run efficiently. This intent declaration is the deeper value and the foundation of high-bandwidth data movement.

12. What Comes Next

You now understand bursts at a high level. The next chapters detail each burst type:

• 8.2 — SINGLE Transfers (coming next) — the degenerate single-beat 'burst' and when it's used.
• 8.3 — INCR (Undefined-Length) Bursts (coming soon) — unbounded incrementing bursts and how they terminate.

To revisit the beat marking, see Transfer Types Overview, NONSEQ Transfers, and SEQ Transfers. For the HBURST signal itself, see HBURST. For the broader protocol map, see the AMBA family overview.