Burst Efficiency

Chapter 14.4 covered the loss bursts don't fix (wait states); this chapter covers the one they do: the address-phase overhead, and how bursts amortise it. A burst pays one address-phase cycle and then N data beats (the pipeline overlaps subsequent addresses, chapter 14.3), so its efficiency = N/(N+1). The curve rises fast: a single transfer is 1/2 = 50%; an INCR4 burst is 4/5 = 80%; INCR8 is 8/9 = 89%; INCR16 is 16/17 = 94% — approaching 100% for long bursts. So bursts amortise the fixed 1-cycle address overhead over more data beats, which is the tool for raising single-path efficiency (chapter 14.1/14.3). But the limits matter: bursts fix the address overhead only — they don't fix wait states (per-beat, capping efficiency at 1/(1+W), chapter 14.4); re-arbitration / short bursts re-pay the overhead; and burst length is bounded by the access pattern (you need a contiguous, known address sequence to burst). This chapter quantifies the burst-efficiency curve and its limits — the precise complement to the wait-state penalty.

1. What Is It?

Burst efficiency is the throughput efficiency of a burst, set by how well it amortises the address-phase overhead. Quantified:

• The formula: efficiency = N/(N+1) — 1 address cycle + N data beats, so N data cycles out of N+1 total.
• The curve: N=1 → 50%, N=4 → 80%, N=8 → 89%, N=16 → 94% — rising toward 100%.
• What it fixes: the address-phase overhead (per-transaction) — amortised over the N beats.
• What it doesn't fix: wait states (per-beat, chapter 14.4) and the access-pattern/arbitration limits.

So burst efficiency is the amortisation of the address-phase overhead: a single transfer "wastes" half its cycles on the address phase (50%), but a burst spreads that one address cycle over many data beats, so the overhead's fraction shrinks (N/(N+1) → 1 as N grows). It's the positive counterpart to chapter 14.1's "single ≈ 50%" — bursts are how you escape the 50% and approach 100% on a single path. This is the tool the pipelining benefit (chapter 14.3) relies on: bursts keep the pipeline full (back-to-back, known addresses) and amortise the address overhead. So burst efficiency is the N/(N+1) curve — the quantified payoff of bursting, and the means to high single-path throughput (subject to the wait-state and access-pattern limits).

2. Why Does It Exist?

Burst efficiency exists because the address-phase overhead is a fixed per-transaction cost that a burst can spread over its data beats — so the more beats per address phase, the smaller the overhead's fraction, giving the N/(N+1) amortisation.

The fixed per-transaction overhead is the root: each transaction needs one address phase (chapter 14.1) — a fixed cost, independent of how many beats follow. A single transfer (1 beat) pays this 1 address cycle for 1 beat = 50% overhead. But the address phase is per transaction, not per beat — so if a transaction has many beats (a burst), the same 1 address cycle covers all of them. So the overhead is amortisable over the beats. So burst efficiency exists because the address overhead is fixed-per-transaction (spreadable), not per-beat. So more beats = less overhead per beat.

The N/(N+1) amortisation is the math: a burst of N beats takes 1 address cycle + N data cycles = N+1 total cycles, of which N carry data. So efficiency = N data cycles / (N+1) total = N/(N+1). As N grows, N/(N+1) → 1 (100%). So the formula is the data-fraction of the burst's cycles, and it rises toward 1 as the fixed 1-cycle overhead becomes a smaller fraction of the growing total. So burst efficiency exists with this form because the address overhead is a fixed numerator-of-one in the overhead, amortised over N. So the curve rises asymptotically to 100%.

The reason this is the loss bursts fix (and the complement to wait states) is the per-transaction vs per-beat distinction (chapter 14.4): the address overhead is per-transaction, so a burst (one transaction, many beats) amortises it. Wait states are per-beat, so a burst can't amortise them (every beat pays). So bursts fix the address overhead (N/(N+1) → 100%) but not wait states (capped at 1/(1+W)). So burst efficiency exists as the fixable loss — the one bursts are for. So burst efficiency exists because: the address overhead is fixed per-transaction (spreadable over beats — the opportunity), the N/(N+1) form is the data-fraction rising toward 100% as the fixed overhead is amortised (the math), and it's the address loss (per-transaction) that bursts can fix — distinct from the wait-state loss (per-beat) they can't (the scope). So burst efficiency is the quantified benefit of bursting — the way to escape the single-transfer 50% and approach 100% on a single path — bounded by the wait-state penalty (which bursts don't touch) and the access pattern (which limits burst length). So this chapter quantifies how much bursts help (N/(N+1)) and what they don't fix (wait states, pattern limits).

3. Mental Model

Model burst efficiency as the setup cost of a machine run — a factory machine needs a fixed setup (calibration, loading the program) before it can produce parts; if you run one part per setup, the setup dominates (half your time is setup), but if you run many parts per setup (a batch), the setup is amortised over the batch and most of your time is productive; the efficiency is parts ÷ (parts + setup), rising toward 100% with batch size — but the setup amortisation doesn't help if each part itself is slow to make (that's a per-part cost, like wait states).

A factory machine (the bus) makes parts (data beats). Before each run, it needs a fixed setup (calibration, loading the program — the address phase). If you do a run of one part per setup, you spend one setup + one part — half your time is setup (50% efficient, the single transfer). But if you batch many parts per setup (a burst of N parts), you spend one setup + N parts — the setup is amortised over the N parts, so the productive fraction is N/(N+1), rising toward 100% as the batch grows. A 4-part batch is 80% productive, a 16-part batch 94%. So batching amortises the fixed setup. But — and this is the limit — the setup amortisation does nothing for a per-part slowness: if each part itself takes extra time to make (a slow process step — like wait states), batching doesn't help that (every part still takes its extra time), and that per-part slowness caps your efficiency separately. Also, you can only batch parts that are the same job (a contiguous run); if the jobs are scattered (different setups), you can't batch them (the access-pattern limit). So batch big to amortise setup, but per-part slowness and job-scattering still limit you.

This captures burst efficiency: the fixed setup per run = the address-phase overhead (per transaction); parts per setup = beats per burst (N); parts ÷ (parts + setup) = N/(N+1); batching amortising setup = the burst amortising the address overhead; per-part slowness not helped by batching = wait states (per-beat, not amortised); scattered jobs can't batch = the access-pattern limit on burst length. Batch big to amortise setup — but per-part slowness (wait states) and job-scattering (pattern) still limit you.

Watch a burst amortise the address phase:

The model's lesson: batch big to amortise the setup — but per-part slowness and scattering still limit you. In the waveform, the 4-beat burst amortises the one address cycle over 4 data beats → 80% (vs 50% for a single), and a longer burst would approach 100%.

4. Real Hardware Perspective

In hardware, burst efficiency is realized by burst-capable masters and slaves using HBURST (chapter 8.x), with the address-sequence known in advance — and its limits (wait states, re-arbitration, pattern) are concrete hardware/workload constraints.

The burst mechanism: a master issues a burst via HBURST (INCR, INCR4, WRAP4, INCR8, INCR16, etc., chapter 8.x), declaring the burst type so the addresses are known (incrementing or wrapping from the start address). So the master can issue the addresses back-to-back without computing each (keeping the pipeline full, chapter 14.3), and one address phase (with the burst type) covers the sequence. The slave, knowing it's a burst, can optimize (e.g. open a memory row once, prefetch the sequence). So in hardware, bursts use HBURST to declare a known address sequence, enabling back-to-back issue and the N/(N+1) amortisation. So burst efficiency is realized via HBURST.

The wait-state limit is the key one (chapter 14.4): bursts amortise the address overhead, but not wait states (per-beat). So a burst to a slow slave is capped at 1/(1+W) — e.g. an INCR16 burst (N/(N+1) = 94% for address overhead) to a 1-wait-state slave is capped at 1/(1+1) = 50% by the wait states (the address amortisation is moot — the wait states dominate). So in hardware, the combined efficiency is N/(N+1) times the wait-state factor — and if W > 0, the wait states usually dominate. So a burst helps only if the slave is fast (low W). So bursts and fast slaves go together.

The re-arbitration and pattern limits: re-arbitration — if a long transfer is split into many short bursts (e.g. due to a maximum burst length, or re-arbitration between bursts, chapter 14.6), each short burst re-pays the address overhead, lowering the effective efficiency — so longer bursts (fewer re-arbitrations) are better. Access pattern — a burst needs a contiguous, known address sequence (incrementing/wrapping); scattered access (random addresses) can't be bursted (each is a single transfer, 50%). So the data layout (contiguous vs scattered) bounds the usable burst length. So in hardware, burst efficiency = N/(N+1) (address amortisation) capped by the wait-state factor (slow slaves) and bounded by the access pattern (contiguity) and re-arbitration (burst length). So to realize high burst efficiency: long bursts (HBURST), contiguous data (so you can burst long), fast slaves (so wait states don't cap it), and minimal re-arbitration. So the hardware reality: bursts amortise the address overhead toward 100%, but only fast slaves + contiguous data + long bursts deliver it.

5. System Architecture Perspective

At the system level, burst efficiency is why DMA and cache-line traffic use long bursts — and the combination of bursts + fast slaves + contiguous layout is the recipe for high single-path throughput, with bursts being the amortisable half of the efficiency story.

The DMA and cache-line traffic: the highest-bandwidth bus users — DMA (streaming buffers) and caches (filling cache lines) — naturally use long bursts: a DMA streams a contiguous buffer (a perfect burst), and a cache fills a contiguous line (a fixed-length burst, e.g. INCR4/INCR8 for a 16/32-byte line). So these high-bandwidth users exploit burst efficiency — their traffic is designed as bursts to amortise the address overhead. So at the system level, burst efficiency is why DMA and cache traffic is structured as bursts. So bandwidth-bound traffic is bursted by design.

The bursts + fast slaves + contiguous layout recipe: high single-path throughput requires all three: long bursts (amortise address overhead → N/(N+1) → 100%), fast slaves (low W → wait states don't cap it), and contiguous data layout (so you can burst long). Missing any one limits the throughput: short bursts (high address overhead), slow slaves (wait-state cap), or scattered data (can't burst). So the architect co-designs for all three — placing bandwidth-bound data contiguously in fast memory and accessing it in long bursts. So at the system level, burst efficiency is one leg of the high-throughput recipe (with fast slaves and contiguous layout) — and it's the amortisable leg (the address overhead, fixable by bursting), complementing the non-amortisable leg (wait states, fixable only by faster slaves). So the recipe combines both.

The composing the efficiency story: chapters 14.1–14.5 together give the single-path efficiency model: efficiency ≈ (address-amortisation: N/(N+1)) × (wait-state factor: 1/(1+W)) × (no-idle factor: keep the pipeline full). So burst efficiency (N/(N+1)) and the wait-state penalty (1/(1+W)) are the two multiplicative factors, and the pipelining benefit (chapter 14.3) is realizing them with a full pipeline. So the architect can estimate a path's efficiency by multiplying these factors — and attack the dominant loss (long bursts if address-overhead-bound; faster slaves if wait-state-bound). So at the system level, burst efficiency is the address-overhead-amortisation factor in the multiplicative single-path efficiency model, the reason DMA/cache traffic is bursted, and one leg of the bursts-fast-slaves-contiguous-layout recipe for high throughput. Understanding it (and its complement, the wait-state penalty) lets the architect decompose a path's efficiency into its factors and optimize the dominant one. So burst efficiency is the fixable-by-bursting half of single-path throughput — essential to the performance toolkit. So bursting is the first lever, with fast slaves the second.

6. Engineering Tradeoffs

Burst efficiency embodies the amortise-the-address-overhead, bounded-by-pattern design.

• Long bursts vs short/single. Long bursts amortise the address overhead (N/(N+1) → 100%), maximizing efficiency, at the cost of needing contiguous data and burst-capable master/slave. Short/single transfers waste the overhead (50% for single). Use long bursts for bandwidth.
• Bursts (fix address overhead) vs faster slaves (fix wait states). Bursts fix the address overhead but not wait states; faster slaves fix wait states but not the address overhead. For high throughput you need both — they're complementary. Apply each to its loss.
• Contiguous layout vs scattered. Contiguous data lets you burst long (high efficiency); scattered data forces single transfers (50%). Lay out bandwidth-bound data contiguously.
• Fewer long bursts vs many short bursts. Fewer long bursts (one address phase each) beat many short bursts (re-paying the address overhead each time) — so avoid unnecessary re-arbitration / burst splitting.

The throughline: a burst pays 1 address cycle then N data beats, so efficiency = N/(N+1) — rising from 50% (single) to 80% (INCR4) to 94% (INCR16), approaching 100% — because the fixed address overhead is amortised over the beats. Bursts fix the address-phase overhead (the per-transaction loss). They don't fix wait states (per-beat, capping at 1/(1+W)) — so a burst to a slow slave is still capped by W; and burst length is bounded by the access pattern (contiguity) and re-arbitration. High single-path throughput needs bursts + fast slaves + contiguous layout together. Burst efficiency is the amortisable factor in the multiplicative efficiency model (× the wait-state factor × the no-idle factor).

7. Industry Example

Apply burst efficiency to a cache-line fill and a DMA stream.

A cache fills 32-byte lines and a DMA streams a buffer, on a 32-bit (4-byte) bus.

• Cache-line fill (fixed burst). A 32-byte line = 8 words = an INCR8 burst. Efficiency from address overhead: 8/9 = 89%. To a fast SRAM (W=0): combined ≈ 89% — good. The cache uses a fixed-length burst matched to the line size, naturally amortising the address overhead.
• DMA stream (long burst). The DMA streams a large contiguous buffer — it can use long bursts (INCR16 or longer), efficiency 16/17 = 94%+. To fast SRAM: combined ≈ 94%+ — near peak. The DMA's contiguous access enables long bursts.
• DMA to slow flash (wait-state cap). If the DMA streamed from flash (W=3), even a long burst (94% address efficiency) is capped at 1/(1+3) = 25% by the wait states → combined ≈ 24%. The long burst barely helped — the flash's wait states dominate. The fix is not a longer burst; it's a faster source (cache/prefetch the flash, or a flash accelerator).
• Scattered access (can't burst). If the DMA gathered scattered (non-contiguous) data — e.g. a scatter-gather list of single words — it can't burst (each is a single transfer, 50%). The fix: gather into contiguous buffers where possible, or accept the lower efficiency for genuinely scattered data.
• Short bursts (re-arbitration). If the DMA were forced into many short (INCR4) bursts with re-arbitration between them (e.g. fair sharing with another master), each pays the address overhead (80% each) plus arbitration gaps (chapter 14.6) — lower than long bursts. Longer bursts (fewer re-arbitrations) are more efficient.
• Recipe. The DMA achieves high throughput with long bursts (amortise address overhead) to fast SRAM (no wait-state cap) on contiguous data (enables long bursts) with minimal re-arbitration — all three legs of the recipe.

The example shows burst efficiency in action: cache-line and DMA traffic use bursts to amortise the address overhead (89-94%), but the benefit is capped by slow slaves (flash → 24%) and bounded by the access pattern (scattered → can't burst). High throughput needs bursts and fast slaves and contiguous data. This is how burst efficiency is computed and realized.

8. Common Mistakes

9. Interview Insight

Burst efficiency is a quantitative interview topic — the N/(N+1) curve, the address-overhead-only scope, and the combined-with-wait-states factor are the signals.

The answer that lands gives the curve and the scope: "A burst pays one address-phase cycle and then N data beats, so its efficiency is N over N+1. That rises fast: a single transfer is 1/2, 50%; a 4-beat burst is 4/5, 80%; an 8-beat is 8/9, 89%; a 16-beat is 16/17, 94% — approaching 100% for long bursts. The reason is that the fixed one-cycle address overhead is amortised over more data beats, so its fraction shrinks. So bursts are the tool to escape the single-transfer 50% and approach 100% on a single path. But the key scope is that bursts only fix the address-phase overhead — they do not fix wait states. Wait states are per-beat, so a burst can't amortise them; the combined efficiency is roughly N over N+1 times 1 over 1 plus W. So a long INCR16 burst to a fast zero-wait slave is about 94%, but the same burst to a 3-wait-state slave is capped at 1/(1+3), 25% — the burst barely helped because the wait states dominate. So you need both long bursts and a fast slave — they fix different losses. And burst length is bounded by the access pattern: you need a contiguous, known address sequence to burst, so scattered access can't burst, and re-arbitration or max-burst limits split long transfers into shorter bursts that re-pay the overhead. So bursts amortise the address overhead toward 100%, but wait states still cap efficiency and the pattern bounds the length." The N/(N+1) curve, the address-overhead-only scope, and the combined-factor point are the senior signals.

10. Practice Challenge

Compute and reason from burst efficiency.

1. The curve. Compute the efficiency for N = 1, 2, 8, 32, and note the diminishing returns.
2. Address overhead only. Explain why bursts fix the address overhead but not wait states.
3. Read the waveform. From Figure 2, explain how the 4-beat burst achieves 80% (vs 50% single).
4. Combined. Compute the combined efficiency of an INCR16 burst to a W=2 slave.
5. The recipe. State the three legs of high single-path throughput and burst efficiency's role.

11. Key Takeaways

• Burst efficiency = N/(N+1) — 1 address cycle amortised over N data beats: 50% (single) → 80% (INCR4) → 89% (INCR8) → 94% (INCR16) → ~100% for long bursts.
• Bursts fix the address-phase overhead (per-transaction) — the loss they do fix — by amortising the fixed 1-cycle overhead over the beats. Diminishing returns past ~8-16 beats.
• Bursts do NOT fix wait states (per-beat) — combined efficiency ≈ N/(N+1) × 1/(1+W); a long burst to a slow slave is capped by the wait states (the address amortisation is moot).
• You need bursts AND fast slaves — complementary fixes for different losses (bursts → address overhead; fast slaves → wait states). High throughput needs both.
• Burst length is bounded by the access pattern — you need contiguous, known addresses to burst (scattered access → single transfers, 50%); re-arbitration / max-burst limits split long transfers.
• The high-throughput recipe: long bursts + fast slaves + contiguous layout — burst efficiency is the address-overhead-amortising leg; decompose efficiency into factors and fix the dominant loss.

12. What Comes Next

You now understand burst efficiency — the address-overhead amortisation (N/(N+1)) and its limits. Combined with the wait-state penalty (chapter 14.4), you can decompose single-path efficiency. The next chapters cover the remaining effects:

• Arbitration Overhead (next) — the cost of bus handover and grant latency (the per-grant overhead).
• Bridge Penalty, Bottleneck Analysis, Performance Debug — the bridge cost, locating bottlenecks, and the debug method.

To revisit bursts themselves, see HBURST and INCR & WRAP Bursts; for the complementary wait-state loss, see Wait-State Penalty.