HSIZE Encoding

This opens Module 9 — Transfer Size and Alignment, the dedicated treatment of how AHB conveys per-transfer width and placement. The first chapter is the complete HSIZE encoding. HSIZE is a 3-bit field giving 2^HSIZE bytes per beat — eight values from 1 byte (8-bit) at 000 up to 128 bytes (1024-bit) at 111. The lower values — byte, halfword, word, doubleword — are common; the wider values (16–128 bytes) are used only on very wide data buses. The fundamental constraint: HSIZE must not exceed the data bus width (the data must fit on the bus). Module 8's "Beat Size" chapter introduced HSIZE in the burst context (the address increment, the WRAP block unit); this chapter is the dedicated encoding reference — all eight values, their bit widths, and the bus-width constraint — the foundation for the size and alignment topics that follow.

1. What Is It?

HSIZE is a 3-bit address-phase field encoding the bytes per beat as 2^HSIZE:

So HSIZE spans a wide range: from a single byte (8 bits) up to 128 bytes (1024 bits). The common four — byte, halfword, word, doubleword — cover most real accesses (most systems use 32- or 64-bit buses, so word or doubleword is the max). The wide four — 16, 32, 64, 128 bytes — exist for very wide data buses (128-bit and beyond), used in high-bandwidth systems. The encoding is uniform: each step doubles the size. HSIZE tells the subordinate the access width — fundamental for knowing how much data the transfer moves and which data-bus lanes carry it.

2. Why Does It Exist?

HSIZE exists because the bus must convey how wide each transfer is — accesses range from a single byte to wide multi-word beats — and the subordinate needs this width to know how much data moves and which bus lanes carry it.

Different accesses have different natural widths: a byte-wide register, a 16-bit halfword, a 32-bit word, a 64-bit doubleword, or — on wide buses — even wider beats. The subordinate must know which width each transfer is, to handle the right number of bytes and route them on the right data-bus lanes. HSIZE is that signal. So HSIZE exists to express per-transfer width — a fundamental need, since without it the subordinate couldn't tell a byte access from a word access. This is the most basic role: convey the access size.

The reason the encoding goes all the way to 128 bytes (1024-bit) is to support very wide data buses in high-bandwidth systems. While most systems use 32- or 64-bit buses (max word or doubleword), some high-performance designs use much wider buses (128, 256, 512, even 1024 bits) to move more data per cycle. HSIZE's range accommodates these: a 1024-bit bus can use HSIZE up to 111 (128 bytes/1024 bits). So the wide encodings exist to let HSIZE scale to the widest buses — future-proofing the encoding for high-bandwidth designs. Most systems never use the wide values, but they exist so the encoding covers the full range of bus widths.

The reason HSIZE must not exceed the bus width is physical: a beat's data travels on the data bus in one transfer, so it must fit — the beat size can't be larger than the bus. A 32-bit bus can't carry a doubleword (64-bit) beat in one transfer; it caps HSIZE at word. So the bus width bounds the legal HSIZE values: a system uses only HSIZE values its bus can carry. This constraint exists because HSIZE describes data that physically moves on the bus — the bus width is the hard limit. So the encoding offers eight values, but any given system uses only those up to its bus width. This is why the wide HSIZE values require wide buses — they're only legal where the bus can carry them.

3. Mental Model

Model HSIZE as the "ship size" label on a package — it tells the carrier how big each shipment is, from a small envelope up to a freight container, and the carrier's vehicle (the bus) must be big enough to carry it.

Shipping packages (transfers), each has a size label (HSIZE): a small envelope (byte), a small box (halfword), a medium box (word), a large box (doubleword), or — for big shipments — a pallet or even a freight container (the wide values, 16–128 bytes). The label tells the carrier (subordinate) how big the shipment is, so it knows how to handle it and how much space it takes. But the vehicle carrying it (the data bus) has a maximum capacity — you can't put a freight container on a small van (HSIZE can't exceed the bus width). A small van (32-bit bus) handles up to a medium box (word); a large truck (wide bus) can carry pallets and containers (the wide HSIZE values). So the size label spans a wide range (envelope to container), but the vehicle's capacity caps which sizes you can actually ship.

This captures HSIZE: the size label = HSIZE (the access width, from byte to 128 bytes); envelope to container = the eight encodings (8-bit to 1024-bit); the vehicle's capacity = the data bus width (the cap); can't put a container on a small van = HSIZE ≤ bus width. The label expresses the size; the bus width limits which sizes are carriable.

Watch HSIZE on the bus:

The model's lesson: HSIZE is the size label — it encodes each transfer's width (2^HSIZE bytes), and the bus width must be big enough to carry it. In the waveform, HSIZE steps through byte, halfword, word, doubleword (1/2/4/8 bytes) — the subordinate reads it to know each transfer's width. The doubleword needs at least a 64-bit bus to fit.

4. Real Hardware Perspective

In hardware, HSIZE is a 3-bit address-phase signal that, with the low address bits, determines the active data-bus byte lanes for the transfer — and the bus width physically caps the usable HSIZE values.

HSIZE is presented with each transfer's address (alongside HADDR, HWRITE, HBURST). The subordinate decodes HSIZE to know the access width: a byte transfer (000) is 1 byte, a word (010) is 4 bytes, etc. Combined with the low address bits (the byte offset within the bus width), HSIZE determines which byte lanes of the data bus carry valid data (chapter 9.5 details lane selection). So HSIZE's hardware role is to size the access and, with the address, select the lanes. For a write, this tells the subordinate which HWDATA lanes to capture; for a read, which lanes to drive on HRDATA. So HSIZE is fundamental to the data-bus byte-lane handling.

The bus-width cap is a hardware constraint: the data bus has a fixed width (e.g., 32 or 64 bits), and a beat's data must fit on it, so 2^HSIZE ≤ bus-width-bytes.

So on a 32-bit (4-byte) bus, the legal HSIZE values are byte, halfword, and word (000–010); doubleword and wider are illegal (too big to fit). On a 64-bit bus, up to doubleword (011). On a 128-bit bus, up to 100 (16 bytes). And so on. So the bus width determines which HSIZE values are usable — a hardware fact that bounds the encoding's use in any given system. A master must not issue an HSIZE larger than the bus, and the subordinate is built for the bus's width.

The wide HSIZE values (100–111, 16–128 bytes) require correspondingly wide data buses. These are used in high-bandwidth designs: a 256-bit bus might use 32-byte beats, a 1024-bit bus 128-byte beats — moving large amounts per cycle. So the wide encodings are real and used in wide-bus systems (high-performance interconnects, graphics, datacenter), even though typical embedded AHB (32/64-bit) never goes beyond word/doubleword. So HSIZE's full range exists for the spectrum of bus widths from narrow embedded buses to very wide high-bandwidth buses.

A hardware note on natural alignment: HSIZE-sized accesses are expected to be naturally aligned — the address aligned to the access size (a word access at a word-aligned address, etc., chapter 9.3). This makes the byte-lane selection clean (a contiguous, aligned set of lanes). So HSIZE, with a naturally-aligned address, gives an unambiguous lane mapping. AHB generally does not support unaligned accesses (chapter 9.4) — accesses are aligned to their HSIZE. So the encoding assumes natural alignment, which keeps the hardware lane handling simple.

5. System Architecture Perspective

At the system level, HSIZE's range maps to the spectrum of data bus widths — from narrow embedded buses to very wide high-bandwidth buses — and the bus width (which caps HSIZE) is a fundamental cost/performance architectural choice.

The bus-width spectrum is what HSIZE's range serves. Embedded systems typically use 32-bit buses (HSIZE up to word) — sufficient bandwidth at low cost/power. Higher-performance systems use 64-bit (up to doubleword) or wider buses. Very high-bandwidth systems (graphics, networking, datacenter accelerators) use 128/256/512/1024-bit buses (the wide HSIZE values) to move large amounts per cycle. So HSIZE's eight encodings span the full range of bus widths a system might use. The architecture picks the bus width for its bandwidth needs, and HSIZE accommodates whatever width is chosen. So HSIZE is the per-transfer size signal that scales across the whole bus-width spectrum.

The bus width as a cost/performance knob is the key architectural point: a wider bus moves more data per cycle (higher bandwidth) but costs more (wires, area, power, routing complexity). So the bus width is chosen to balance bandwidth against cost — a narrow bus for low-cost/low-power embedded, a wide bus for high-bandwidth. And the bus width caps HSIZE (the max beat size). So HSIZE's usable range in a system is determined by this fundamental bus-width decision. This is why HSIZE's encoding goes so wide — to support the high-bandwidth end of the spectrum — even though most systems use only the lower values. The encoding is general; the system uses the part its bus width allows.

The mixed-width consideration arises when components of different native widths share a bus: a byte-wide peripheral, a word-wide memory, on the same 32-bit bus. HSIZE lets each transfer be the right size for its target (a byte access to the byte peripheral, a word access to the memory), and the lane selection (HSIZE + address) routes the data correctly. So HSIZE supports a heterogeneous set of access widths on one bus — narrow accesses to narrow devices, wide accesses to wide ones — all within the bus width. So at the system level, HSIZE enables mixed-width access patterns on a common bus, with the bus width as the upper bound. This flexibility — any access width up to the bus width — is what lets diverse devices coexist, each accessed at its natural width. So HSIZE's role spans the bus-width spectrum (via its range) and supports heterogeneous widths within a bus (via per-transfer sizing), all capped by the architectural bus-width choice.

6. Engineering Tradeoffs

HSIZE's encoding reflects the cover-the-full-range, cap-at-bus-width design.

• Wide encoding (8 values) vs minimal. Encoding eight sizes (byte to 128 bytes) covers the full bus-width spectrum (narrow embedded to very wide high-bandwidth) at the cost of 3 bits and unused values in narrow-bus systems. A minimal encoding (just byte/halfword/word) would be cheaper but couldn't serve wide buses. AHB covers the full range — generality for the spectrum of systems.
• HSIZE ≤ bus width. The constraint that the beat fits the bus is physical and non-negotiable — the bus width caps HSIZE. This means a system uses only the lower HSIZE values if its bus is narrow; the wide values need wide buses. The cap is a hard limit.
• Wide bus (bandwidth) vs narrow bus (cost). A wider bus enables wider HSIZE (more per beat, more bandwidth) at higher cost (wires, area, power). The bus width is the cost/performance choice that determines the usable HSIZE range. Most embedded systems choose narrow buses (32-bit) for cost.
• Natural alignment vs unaligned support. Assuming naturally-aligned accesses (address aligned to HSIZE) keeps the byte-lane selection clean, at the cost of not supporting unaligned access directly (chapter 9.4). AHB requires alignment — simpler hardware.

The throughline: HSIZE is a 3-bit field encoding 2^HSIZE bytes per beat — eight values from byte (8-bit) to 128 bytes (1024-bit) — covering the full spectrum of data bus widths. The bus width caps the usable values (2^HSIZE ≤ bus width): narrow embedded buses use the low values (up to word), wide high-bandwidth buses use the high values. HSIZE conveys the per-transfer width (selecting the data-bus byte lanes, with the address) and supports heterogeneous access widths on one bus. The encoding is general; each system uses the part its bus width allows.

7. Industry Example

Trace HSIZE values across systems of different bus widths.

Several systems use HSIZE according to their bus widths.

• A 32-bit embedded system. A typical microcontroller has a 32-bit AHB. It uses HSIZE byte (000), halfword (001), and word (010) — the three legal values for a 32-bit bus. Word is the max and the streaming choice (cache fills, DMA use word beats); byte/halfword are used for narrow peripheral accesses. Doubleword and wider are never used (too big for the 32-bit bus). So this common system uses only the lower three HSIZE values.
• A 64-bit higher-performance system. A more capable SoC has a 64-bit AHB. It uses up to doubleword (011, 8 bytes) — streaming with doubleword beats for double the per-beat bandwidth of the 32-bit system. So it uses HSIZE up to 011. The wider values are still unused (the bus is 64-bit).
• A 256-bit high-bandwidth interconnect. A high-performance datapath (e.g., for graphics or networking) uses a 256-bit bus. It uses HSIZE up to 101 (32 bytes / 256 bits) — streaming 32-byte beats for very high bandwidth. So this system uses the wide HSIZE values that the embedded systems never touch. The wide encodings exist precisely for systems like this.
• Mixed-width access on one bus. Within the 32-bit system, a byte-wide UART register is accessed with HSIZE byte (000), while word-wide memory is accessed with HSIZE word (010) — different sizes for different targets, all on the 32-bit bus, with the lane selection routing each correctly. So HSIZE supports heterogeneous widths on one bus.
• The bus-width cap in action. If a master in the 32-bit system tried to issue a doubleword (011) access, it would be a protocol error — the 8-byte beat can't fit on the 4-byte bus. So the system's HSIZE use is capped at word by its bus width. The wide values are simply not available without a wider bus.

The example shows HSIZE's range mapping to bus widths: a 32-bit embedded system uses byte/halfword/word; a 64-bit system up to doubleword; a 256-bit high-bandwidth system the wide values; and within a bus, mixed widths for different devices — all capped by the bus width. The full encoding exists to serve this spectrum, with each system using the part its bus allows.

8. Common Mistakes

9. Interview Insight

HSIZE encoding is a foundational interview check — knowing the full range and the bus-width constraint is the signal.

The answer that lands gives the encoding and the constraint: "HSIZE is a 3-bit field that encodes the bytes per beat as 2 to the HSIZE — so 1 byte at 000, 2 (halfword) at 001, 4 (word) at 010, 8 (doubleword) at 011, then 16, 32, 64, and 128 bytes for the wide values up to 111. Equivalently, 8-bit up to 1024-bit. The common four — byte, halfword, word, doubleword — cover most systems, since most use 32- or 64-bit buses; the wide values exist for very wide data buses in high-bandwidth designs. The key constraint is that HSIZE must not exceed the data bus width — the beat's data has to fit on the bus in one transfer, so a 32-bit bus caps HSIZE at word, a 64-bit bus at doubleword, and the wide values need correspondingly wide buses. HSIZE conveys the access width, which the subordinate uses, with the low address bits, to select the active data-bus byte lanes. And accesses are naturally aligned to their size." The full range, the bus-width constraint, and the lane-selection role are the senior signals.

10. Practice Challenge

Reason from the HSIZE encoding.

1. Decode it. Give the bytes and bits for HSIZE = 000, 010, 011, 111.
2. Bus-width cap. State the maximum HSIZE on a 32-bit and a 64-bit bus, and why.
3. Read the waveform. From Figure 2, identify the four transfer sizes and which needs at least a 64-bit bus.
4. Wide values. Explain why HSIZE goes to 1024-bit and which systems use the wide values.
5. Lane role. Explain how HSIZE, with the address, selects the data-bus byte lanes.

11. Key Takeaways

• HSIZE is a 3-bit field encoding 2^HSIZE bytes per beat — eight values from 1 byte (8-bit, 000) to 128 bytes (1024-bit, 111), each step doubling.
• The common four are byte (000), halfword (001), word (010, most common), and doubleword (011); the wide four (16/32/64/128 bytes) are for very wide data buses in high-bandwidth systems.
• HSIZE must not exceed the data bus width (2^HSIZE ≤ bus width) — a 32-bit bus caps HSIZE at word, a 64-bit bus at doubleword, and the wide values need wide buses.
• HSIZE, with the low address bits, selects the active data-bus byte lanes — it conveys the access width that routes the data.
• The encoding's range maps to the bus-width spectrum — narrow embedded buses use the low values, wide high-bandwidth buses use the high values; the bus width is a cost/performance choice.
• Accesses are naturally aligned to their HSIZE — AHB generally doesn't support unaligned access; the alignment keeps lane selection clean.

12. What Comes Next

You now know the full HSIZE encoding. The next chapters cover the common sizes and alignment in detail:

• 9.2 — Byte, Halfword & Word Transfers (coming next) — the three common transfer sizes and their data-bus lane usage.
• 9.3 — Aligned Access (coming soon) — the address-alignment requirement for each size.

To revisit the beat size in the burst context, see Beat Size. For the HSIZE signal's place among the control signals, see HSIZE. For how it scales burst addresses, see Burst Address Calculation. For the broader protocol map, see the AMBA family overview.