Beat Size

The burst chapters so far used s (the beat size) as a parameter; this chapter explains what sets it. The beat size is the number of bytes transferred per beat, given by HSIZE as 2^HSIZE (1, 2, 4, 8 … bytes). It plays two roles in bursts: it is the address increment per beat for INCR (the s in start + n×s) and the unit that sizes the WRAP block (B = L × s). The total burst footprint in bytes is beats × beat-size. The beat size also relates to the data bus width: it must not exceed the bus width, and matching it to the bus width gives maximum throughput (the whole bus used each beat), while narrower beats are used only for genuinely narrow accesses. So the beat size scales both the addresses and the data moved — the missing parameter that completes the burst picture.

1. What Is It?

The beat size is the number of bytes transferred per beat, encoded by HSIZE as 2^HSIZE:

• HSIZE=000 → 1 byte (byte), 001 → 2 bytes (halfword), 010 → 4 bytes (word, the common case), 011 → 8 bytes (doubleword), and larger values (16, 32, 64, 128 bytes) for wide data buses.

The beat size has two roles in bursts. First, it is the address increment per beat: for an INCR burst, each beat's address is the previous plus the beat size (addr[n] = start + n×s, chapter 8.7). Second, it is the unit that sizes the WRAP block: the WRAP block (and wrap boundary) is B = L × s (chapter 8.8). And the total data moved — the burst footprint — is beats × beat-size. So the beat size is the s that scales every burst calculation: a word (4-byte) beat increments addresses by 4 and makes a WRAP4 block 16 bytes; a doubleword (8-byte) beat increments by 8 and makes a WRAP4 block 32 bytes. The beat size is what gives the burst calculations their byte-level concreteness.

2. Why Does It Exist?

The beat size (HSIZE) exists because transfers come in different widths — a byte, a halfword, a word — and the bus must carry the width of each access, both to move the right amount of data and to scale the burst's address progression correctly.

Real accesses have different natural widths: a byte-wide register, a 16-bit halfword, a 32-bit word, a 64-bit doubleword. The bus must convey which width each transfer is, so the subordinate knows how many bytes to read/write and which data-bus lanes carry the data. HSIZE is that signal — it tells the subordinate the access width. So HSIZE exists to express the per-transfer data width, which is fundamental: without it, the subordinate wouldn't know how much data the transfer moves. This is true for single transfers and bursts alike — every transfer has a size.

For bursts specifically, the beat size also scales the address progression: the addresses must increment by the size of each beat (so consecutive beats are adjacent in memory), and the WRAP block must be sized by the beat size. So the beat size is what connects the abstract beat count to concrete byte addresses: a 4-beat word burst spans 16 bytes (4 beats × 4 bytes), incrementing by 4 each beat; a 4-beat doubleword burst spans 32 bytes, incrementing by 8. So HSIZE exists, for bursts, to scale the addresses to the actual data width — it's the byte-size that makes the burst's beats correspond to real adjacent memory locations. Without the beat size, the address increment would be undefined.

The reason the beat size relates to the data bus width is physical: the data bus has a fixed width (e.g., 32 or 64 bits), and a beat's data must fit on it — so the beat size cannot exceed the bus width. And to use the bus efficiently, the beat size should match the bus width (so the whole bus carries data each beat). A narrower beat uses only part of the bus, wasting bandwidth. So HSIZE's relationship to the bus width exists because the data physically travels on the bus: the beat size is bounded by the bus width and is most efficient when it matches. This is why streaming bursts use the full bus width (e.g., word beats on a 32-bit bus) and narrow beats are reserved for genuinely narrow accesses. The bus width caps and ideally matches the beat size.

3. Mental Model

Model the beat size as the size of the boxes you carry on a conveyor belt — bigger boxes carry more per box (more data per beat), the belt has a maximum box size (the bus width), and you space the boxes by their size on the shelf (the address increment).

Moving items on a conveyor belt (the data bus), you pack them into boxes (beats). The box size (the beat size) determines how much each box carries: small boxes (byte beats) carry little, big boxes (word/doubleword beats) carry more. The belt has a maximum box size (the bus width) — you can't use a box bigger than the belt (beat size ≤ bus width), and to move things fastest you use boxes that fill the belt (match the bus width). When you place the boxes on a shelf (memory), you space them by their size — each box goes right after the previous one, spaced by the box size (the address increments by the beat size). And the total shelf space used is the number of boxes times the box size (the burst footprint). So the box size sets how much each beat carries, how the addresses are spaced, and (capped by the belt) how efficiently the belt is used.

This captures the beat size: box size = beat size (data per beat); maximum box size = bus width (the cap); fill the belt = match the bus width (max throughput); spacing by box size = address increment per beat; total shelf space = burst footprint (beats × size). The box size scales both how much moves and how the addresses are laid out.

Watch bursts with different beat sizes:

The model's lesson: the beat size is the box size — it scales the address increment (spacing) and the data per beat. In the waveform, the word burst increments by 4 and the doubleword by 8; the same 4-beat burst spans 16 vs 32 bytes. The beat size is the s that gives the burst its byte-level dimensions.

4. Real Hardware Perspective

In hardware, HSIZE is an address-phase control signal (alongside HBURST, HWRITE) that the subordinate uses to know the access width — determining which data-bus byte lanes carry valid data — and the manager uses it to scale the address increment.

HSIZE (3 bits) is presented with each beat's address, encoding 2^HSIZE bytes. The subordinate reads HSIZE to know the transfer width — for a write, which byte lanes of HWDATA hold valid data; for a read, how wide the returned HRDATA is. So HSIZE drives the subordinate's byte-lane handling: a word access uses all 4 lanes of a 32-bit bus, a byte access uses 1 lane (the one for the addressed byte). So HSIZE, together with the low address bits, determines the active byte lanes on the data bus. This is the hardware role of HSIZE for any transfer: it sizes the data and selects the lanes.

The address-increment scaling is the manager's use of the beat size in a burst: the manager's address generator (chapter 8.7) adds the beat size (2^HSIZE) each beat for INCR, and sizes the WRAP block by L × 2^HSIZE. So HSIZE feeds the address generator's increment. In hardware, the beat size is a shift amount or an increment value derived from HSIZE. A word burst increments by 4; the manager's incrementer adds 4 each beat. So HSIZE is wired into the burst address generation, scaling the increment and the wrap boundary. This is why HSIZE is a parameter in the address formulas — it's the actual increment the hardware applies.

The bus-width relationship is a hardware constraint: the beat size must fit on the data bus, so 2^HSIZE ≤ bus-width-bytes. A 32-bit (4-byte) bus supports beat sizes up to word (4 bytes); a 64-bit bus up to doubleword (8 bytes). The manager must not issue a beat size larger than the bus. And for efficiency, matching the beat size to the bus width uses all the lanes each beat (maximum data per beat). A narrower beat (e.g., a byte beat on a 32-bit bus) uses only one lane, leaving three idle — wasting bandwidth. So in hardware, the beat size is bounded by the bus width and most efficient when it equals it. Streaming logic uses the full-width beat; narrow accesses (byte/halfword to byte-addressable peripherals) use narrow beats out of necessity.

A hardware note on byte lanes and alignment: which byte lanes a beat uses depends on HSIZE and the low address bits (the byte offset). A naturally-aligned access (address aligned to its size) uses a contiguous, aligned set of lanes. AHB transfers are expected to be naturally aligned (the address aligned to the beat size), so the lane selection is clean. So HSIZE plus the aligned address determines the lanes unambiguously. (Unaligned accesses are generally not supported in basic AHB — accesses are aligned to their size.) So the beat size, with the aligned address, gives a clean byte-lane mapping each beat.

5. System Architecture Perspective

At the system level, the beat size choice is about matching the access width to the bus width for throughput while supporting narrow accesses where needed — and the data bus width itself is a key architectural parameter that bounds the beat size.

The throughput goal drives matching the beat size to the bus width: for bulk data movement (DMA, cache fills, streaming), using the full bus width per beat maximizes data moved per beat, hence bandwidth. So a 32-bit-bus system streams with word (4-byte) beats; a 64-bit-bus system with doubleword (8-byte) beats; a 128-bit-bus system with 16-byte beats. So the streaming beat size is set by the bus width — wider buses enable wider beats and more bandwidth. This is why high-bandwidth systems use wide data buses (and wide beats): the beat size scales with the bus width, and the bus width sets the peak bandwidth. So the data bus width is a primary architectural knob, and the beat size follows it for streaming.

Narrow accesses still need narrow beats: a byte-wide peripheral register, a 16-bit access to a halfword-addressable device, accessing a single byte within a word. These genuinely move less than the full bus width, so they use narrow beats (byte, halfword) — using only part of the bus. So the system supports narrow beats for narrow accesses, accepting the reduced per-beat bandwidth because the access is inherently narrow. So the beat size isn't always the bus width — it's the access width, which is the bus width for streaming and narrower for narrow accesses. The architecture supports the full range of HSIZE values to handle both.

The data bus width is the architectural parameter that bounds everything: it caps the beat size (2^HSIZE ≤ bus width), sets the peak bandwidth (bus width × clock), and is chosen to meet the system's bandwidth needs. A higher-bandwidth system uses a wider bus (more bytes per beat, more bandwidth); a low-cost/low-power system uses a narrower bus. So the bus width is a fundamental cost/performance tradeoff, and the beat size (for streaming) tracks it. This is why AHB systems come in different bus widths (32, 64, 128 bits), and why wide-bus systems achieve more bandwidth — the wider beats move more per cycle. So the beat size, the bus width, and the system's bandwidth are tightly linked: the bus width is chosen for bandwidth, and the streaming beat size matches it. The beat size is thus part of the system's bandwidth story — the per-beat data width that, times the clock, gives the bandwidth.

6. Engineering Tradeoffs

The beat size embodies the match-width-for-throughput, support-narrow-for-flexibility choice.

• Full-width beats (throughput) vs narrow beats (flexibility). Full-width beats (beat size = bus width) maximize bandwidth (whole bus used each beat) — the streaming choice. Narrow beats (byte/halfword) waste bandwidth but are necessary for genuinely narrow accesses. Use full-width for streaming, narrow for narrow accesses.
• Wide bus (bandwidth) vs narrow bus (cost/power). A wider data bus enables wider beats and more bandwidth, at the cost of more wires, area, and power. A narrower bus is cheaper but lower-bandwidth. The bus width is a cost/performance choice that bounds the beat size.
• Beat size scales the burst. The beat size sets the address increment and WRAP block size, so it scales the burst footprint. A burst of a given beat count moves more data with a larger beat size — but the data width must match the access. The beat size connects the beat count to bytes.
• Aligned accesses (clean lanes) vs unaligned (complex). AHB expects naturally-aligned accesses (address aligned to beat size), giving clean byte-lane mapping. Supporting unaligned accesses would complicate lane handling. AHB requires alignment — simpler lanes, at the cost of not supporting unaligned access directly.

The throughline: the beat size (HSIZE, 2^HSIZE bytes) is the per-beat data width — the address increment, the WRAP block unit, and the data-lane selector. It must fit the data bus width (2^HSIZE ≤ bus width) and is most efficient when it matches it (full-width beats for streaming). Narrow beats serve narrow accesses. The bus width is the architectural parameter that bounds the beat size and sets peak bandwidth, making the beat size part of the system's bandwidth story. The beat size is the s that gives every burst calculation its byte-level concreteness.

7. Industry Example

Trace beat-size choices across a system's traffic.

A system has a 32-bit AHB data bus, a DMA engine, a CPU, and byte-wide peripherals.

• DMA bulk copy — word beats. The DMA copies a large buffer using word (4-byte) beats on the 32-bit bus — the full bus width, so each beat moves 4 bytes (all 4 lanes used). This is maximum throughput: the DMA streams at the bus's peak bandwidth. An INCR burst of word beats increments the address by 4 each beat. Using the full bus width is the efficient streaming choice.
• Cache line fill — word beats. The CPU fills a cache line with a WRAP burst of word beats (the bus width). An 8-word line is a WRAP8 of word beats, spanning 32 bytes (8 × 4). Full-width beats fill the line at peak bandwidth. The beat size (word) sizes the WRAP block (8 × 4 = 32 bytes).
• A byte-wide register — byte beat. The CPU writes a byte-wide peripheral control register using a byte (1-byte) beat (HSIZE=byte). This uses only 1 of the 4 lanes — but the access is genuinely 1 byte (the register is byte-wide), so a narrow beat is correct here. A byte beat is necessary for a byte access; using a word beat would write 4 bytes when only 1 is wanted.
• A halfword access — halfword beat. The CPU accesses a 16-bit value with a halfword (2-byte) beat. Two lanes used. Again, the access is genuinely 2 bytes, so the narrow beat is appropriate.
• A wider bus for more bandwidth. If this system needed more bandwidth, it might use a 64-bit data bus and stream with doubleword (8-byte) beats — double the per-beat data, double the streaming bandwidth. So the bus width and the streaming beat size scale together for bandwidth. The DMA and cache fills would use 8-byte beats, incrementing addresses by 8.
• The efficiency rule in action. The DMA and cache fills use full-width (word) beats for throughput; the byte/halfword accesses use narrow beats because they're genuinely narrow. If the DMA had been (mistakenly) configured for byte beats, it would move data at a quarter the rate — a 4× bandwidth loss. So the system uses full-width beats for streaming and narrow beats only for narrow accesses — matching the beat size to the access width and the bus width.

The example shows beat-size choices by use: full-width (word) beats for bulk DMA and cache fills (maximum throughput), narrow (byte/halfword) beats for genuinely narrow peripheral accesses, and a wider bus (with wider beats) for more bandwidth. The beat size matches the access width — the bus width for streaming, narrower for narrow accesses — with the efficiency rule that streaming should use the full bus width.

8. Common Mistakes

9. Interview Insight

Beat size is a foundational interview check — connecting HSIZE to the address increment, the WRAP block, and the bus width is the signal.

The answer that lands ties HSIZE to its roles: "HSIZE sets the beat size — the bytes per beat — as 2 to the HSIZE: 1 byte, 2 (halfword), 4 (word, the common case), 8 (doubleword), and wider for wide buses. In a burst, the beat size plays two roles: it's the address increment per beat for INCR — each beat's address is the previous plus the beat size — and it's the unit that sizes the WRAP block, which is the beat count times the beat size. The total data moved, the burst footprint, is beats times beat-size. The beat size also relates to the data bus width: it must not exceed the bus width, and for streaming you match it to the bus width so the whole bus carries data each beat — maximum throughput. Narrower beats, like byte or halfword, are used only for genuinely narrow accesses, since they leave some bus lanes idle. So the beat size scales both the addresses and the data moved, and should match the bus width for bulk transfers." The two roles, the bus-width relationship, and the match-for-throughput rule are the senior signals.

10. Practice Challenge

Reason from the beat size.

1. Encode it. State the bytes per beat for HSIZE = byte, halfword, word, doubleword.
2. Scale a burst. Give the addresses and footprint of a WRAP4 of doublewords versus words from 0x00.
3. Bus width. State the maximum beat size on a 32-bit and a 64-bit bus, and why.
4. Efficiency. Explain why streaming should use full-width beats and what byte beats cost on a 32-bit bus.
5. Narrow access. Give an example where a narrow beat is the correct choice.

11. Key Takeaways

• The beat size is the bytes per beat, set by HSIZE as 2^HSIZE — 1 (byte), 2 (halfword), 4 (word, common), 8 (doubleword), and wider for wide buses.
• It has two burst roles: the address increment per beat (INCR: addr[n] = start + n×s) and the unit sizing the WRAP block (B = L × s). The footprint is beats × beat-size.
• It selects the active data-bus byte lanes (with the low address bits) — the subordinate uses it to know which lanes carry valid data.
• It must be ≤ the data bus width — match it to the bus width for maximum throughput (whole bus used each beat); narrow beats leave lanes idle.
• Use full-width beats for streaming (DMA, cache fills) and narrow beats only for genuinely narrow accesses (byte/halfword registers). Narrow beats for bulk movement waste bandwidth.
• The data bus width bounds the beat size and sets peak bandwidth — wide-bus systems stream with wide beats for more bandwidth. The beat size is part of the system's bandwidth story.

12. What Comes Next

You now understand the beat size that scales the burst calculations. The next chapters cover how bursts end and pause:

• 8.10 — Burst Termination (coming next) — early termination and how masters and subordinates handle it.
• 8.11 — BUSY Cycles Inside Bursts (coming soon) — how BUSY pauses a burst without losing the sequence.

To revisit the address math that uses the beat size, see Burst Address Calculation and Boundary Wrapping; for the overview, Burst Overview. For the HSIZE signal itself, see HSIZE. For the broader protocol map, see the AMBA family overview.