Byte, Halfword & Word Transfers

Chapter 9.1 gave the full HSIZE encoding. This chapter walks the three common transfer sizes — byte, halfword, and word — and how each uses the data-bus byte lanes. On a 32-bit bus (four byte lanes), a word transfer uses all four lanes, a halfword uses two adjacent lanes (selected by address bit 1), and a byte uses one lane (selected by the low two address bits). The active lanes carry the transfer's valid data; the others are unused for that transfer. This is the concrete, practical view of how the common sizes map onto the bus — introducing lane usage with the three sizes you'll meet most often (chapter 9.5 generalizes the lane-selection rule). Understanding which lanes each size uses is essential for reading the data bus and for designing the byte-lane handling in masters, slaves, and bridges.

1. What Is It?

The three common transfer sizes and their lane usage on a 32-bit bus (four byte lanes: lane 0 = bits [7:0], lane 1 = [15:8], lane 2 = [23:16], lane 3 = [31:24]):

• Word (4 bytes, HSIZE=010): uses all four lanes — the full bus width.
• Halfword (2 bytes, HSIZE=001): uses two adjacent lanes — lanes 0–1 if address bit 1 is 0, lanes 2–3 if address bit 1 is 1.
• Byte (1 byte, HSIZE=000): uses one lane — selected by the low two address bits (addr[1:0]).

So the size determines how many lanes, and the low address bits determine which lanes. A word uses all four (no choice — it's the full width). A halfword uses two: the lower half (lanes 0–1) or upper half (lanes 2–3), chosen by addr[1]. A byte uses exactly one, chosen by addr[1:0] (00→lane 0, 01→lane 1, 10→lane 2, 11→lane 3). The active lanes carry the transfer's valid data (the bytes being read or written); the inactive lanes are unused for that transfer. This size + address → lanes mapping is how each common size places its data on the bus.

2. Why Does It Exist?

The three common sizes exist because real data comes in these natural widths — 8-bit bytes, 16-bit halfwords, 32-bit words — and each must be accessible at its own width, using only the bus lanes it occupies.

Data is naturally sized: a character or flag is a byte (8 bits), a short integer or audio sample is a halfword (16 bits), a 32-bit integer or pointer or instruction is a word. Each must be read/written at its width — you don't want to read a whole word to get one byte (and risk side effects on the other bytes), nor force a byte into a word access. So the bus supports byte, halfword, and word transfers, each accessing exactly its data. So the three sizes exist to access data at its natural width — the common widths real programs and peripherals use. This is why these three (of HSIZE's eight values) are the common ones: they match the dominant data widths on a 32-bit bus.

The reason each size uses only its lanes (not the whole bus) is correctness and clarity: a byte transfer should affect only the addressed byte, not the other three bytes in the word. By using only the byte's lane, the transfer reads/writes exactly that byte, leaving the others untouched. So lane usage exists to isolate the access to its data — a byte write modifies one byte (one lane), a halfword two, a word four. This matters especially for writes (a byte write must not corrupt the neighboring bytes) and for read-sensitive locations. So the size-determines-lanes behavior exists to make each access affect exactly its own data — using only the relevant lanes.

The reason the low address bits select the lanes is that they specify where within the bus width the data sits. On a 32-bit bus, four bytes map to four lanes by their address offset (addr[1:0]): byte at offset 0 → lane 0, offset 1 → lane 1, etc. A halfword at offset 0 → lanes 0–1, offset 2 → lanes 2–3 (selected by addr[1]). So the low address bits are the byte offset that positions the data on the bus. This is why size and address together determine the lanes: the size says how wide, the address says where. So the lane selection exists to place each access's data at the right position on the bus, per its address — which is what lets a byte at any offset use the correct single lane. The address offset maps the data to its lanes.

3. Mental Model

Model the three sizes as filling slots in a four-slot tray (the 32-bit bus), where a word fills all four slots, a halfword fills an adjacent pair, and a byte fills one slot — and the address tells you which slots.

A serving tray has four slots (the four byte lanes of a 32-bit bus). When you serve a full meal (a word), you fill all four slots — the whole tray. When you serve a half portion (a halfword), you fill two adjacent slots — either the left pair (lanes 0–1) or the right pair (lanes 2–3), depending on where it goes (addr[1]). When you serve a single item (a byte), you fill one slot — slot 0, 1, 2, or 3, depending on its position (addr[1:0]). The size of the portion determines how many slots; the position (address) determines which. The empty slots aren't used for that serving. So you place each serving in exactly the slots it occupies, leaving the rest empty — just as each transfer uses exactly its lanes, leaving the others idle.

This captures the lane usage: the four-slot tray = the 32-bit bus's four byte lanes; full meal/half portion/single item = word/halfword/byte; how many slots = the size; which slots = the low address bits; empty slots = idle lanes. The portion size and its position determine which slots it fills — exactly the size + address → lanes mapping.

Watch the three sizes and their lanes:

The model's lesson: the size fills a number of slots (lanes); the address picks which slots. In the waveform, the word fills all four lanes, the halfword at offset 0 fills lanes 0–1, and the byte at offset 2 fills lane 2 — each transfer occupying exactly its lanes per its size and address. The rest are idle.

4. Real Hardware Perspective

In hardware, the active byte lanes are derived combinationally from HSIZE and the low address bits, and they control which HWDATA lanes a slave captures (writes) or which HRDATA lanes it drives (reads).

The lane derivation is a small combinational function of HSIZE and addr[1:0] (for a 32-bit bus). For a word (HSIZE=010), all four lanes are active. For a halfword (001), addr[1] selects lanes 0–1 or 2–3. For a byte (000), addr[1:0] selects one of the four lanes. So the hardware computes the active-lane mask from HSIZE and the low address bits — a simple decode (chapter 9.5 generalizes this). This mask tells the slave which lanes are valid for the transfer.

For a write, the active-lane mask tells the slave which HWDATA byte lanes to capture (the bytes being written) — the slave writes only those bytes to its storage, leaving the others unchanged. This is crucial: a byte write must modify only the addressed byte, so the slave captures only that lane. So the lane mask is, in effect, a byte-write-enable for the slave's storage. For a read, the active-lane mask tells the slave which HRDATA byte lanes to drive with valid data (the bytes being read); the other lanes are don't-care. So for reads, the slave drives the active lanes and the master reads them. In both cases, the lane mask (from HSIZE + address) governs the byte-lane data handling.

The byte-write-enable role is especially important for writes to memory. A 32-bit memory needs per-byte write enables so a byte write modifies one byte without disturbing the other three. The active-lane mask (derived from HSIZE + address) provides exactly these byte-write-enables: a byte write enables one byte lane, a halfword two, a word all four. So the slave's memory uses the lane mask as its byte-write-enable signals. This is why the lane derivation matters concretely: it's what lets sub-word writes (byte, halfword) modify only their bytes in a word-wide memory. Without it, a byte write would either fail or corrupt the neighboring bytes.

A hardware note on natural alignment (chapter 9.3): the common sizes are naturally aligned — a word at a word-aligned address (addr[1:0]=00), a halfword at a halfword-aligned address (addr[0]=0). This makes the active lanes a contiguous, aligned group: a word uses all four; a halfword uses an aligned pair (0–1 or 2–3, never 1–2); a byte uses any single lane. So natural alignment keeps the lane groups clean (aligned, contiguous), which simplifies the lane-derivation hardware. An unaligned halfword (e.g., at offset 1, spanning lanes 1–2) is not supported (chapter 9.4) — the alignment ensures the lanes form a proper aligned group. So the lane handling assumes natural alignment, which is why AHB requires it.

5. System Architecture Perspective

At the system level, the three common sizes support mixed-width data and devices on a common bus — byte-wide peripherals, 16-bit data, 32-bit memory — each accessed at its natural width, with the lane handling routing data correctly and enabling sub-word writes.

The mixed-width support is the key system benefit: a system has data and devices of different widths — byte-wide UART/GPIO registers, 16-bit ADC samples, 32-bit memory and instructions — and the three sizes let each be accessed at its width. A byte access to a byte register, a halfword access to a 16-bit sample, a word access to memory — all on the same 32-bit bus, with the lane handling placing each access's data on the right lanes. So the three sizes enable a heterogeneous set of data widths on one bus. This is essential: real systems mix widths, and the per-transfer size (with lane handling) accommodates them. Without sub-word sizes, you couldn't cleanly access a byte register or modify a single byte.

The sub-word write capability is a critical system function: software frequently writes individual bytes or halfwords (a character, a flag, a 16-bit field) into byte-addressable memory or registers. The byte/halfword sizes, with the lane-mask byte-write-enables, let these sub-word writes modify exactly their bytes without disturbing the rest of the word. So the three sizes (and the lane handling) are what make byte-addressable memory and byte-granular register access work. This is fundamental to how software interacts with memory and peripherals: it must be able to write a byte without read-modify-writing a whole word. So the sub-word sizes serve this pervasive need — byte-granular access — at the system level.

The endianness consideration (chapter 9.6) interacts with the lane mapping: which byte of a multi-byte value goes on which lane depends on the system's endianness (big- vs little-endian). The size + address → lane mapping is the same, but the byte ordering within the lanes follows the endianness. So at the system level, the lane usage of the common sizes must be consistent with the system's endianness — a system-wide convention. (Chapter 9.6 covers this; here the point is that the lane mapping and endianness together place each byte correctly.) So the three sizes' lane handling is part of the system's data-placement convention, which includes endianness. The common sizes, their lanes, and the endianness together define how multi-byte data sits on the bus — a foundational system convention for correct data interchange between components.

6. Engineering Tradeoffs

The three common sizes and their lane usage reflect the access-at-natural-width design.

• Sub-word sizes vs word-only. Supporting byte and halfword (not just word) lets data be accessed at its natural width and enables sub-word writes (byte-granular) at the cost of the lane-derivation logic. Word-only access would be simpler but couldn't cleanly access bytes or modify single bytes. AHB supports all three — natural-width access is essential.
• Lane mask (byte-write-enables) vs read-modify-write. Using the active-lane mask as byte-write-enables lets a sub-word write modify exactly its bytes directly. The alternative (read-modify-write a whole word in software) is slower and racy. The hardware lane mask is the clean solution — sub-word writes are direct.
• Size + address → lanes vs fixed lanes. Deriving the lanes from the size and address allows any access width at any aligned offset, at the cost of the derivation logic. Fixed lanes would be simpler but inflexible. AHB derives the lanes — flexibility for mixed-width access.
• Natural alignment vs unaligned. Requiring natural alignment keeps the active lanes a contiguous aligned group (simple lane logic), at the cost of not supporting unaligned access. AHB requires alignment — simpler lanes (chapters 9.3–9.4).

The throughline: the three common sizes — byte, halfword, word — access data at its natural width, with the active byte lanes derived from HSIZE and the low address bits (word = all 4, halfword = 2 by addr[1], byte = 1 by addr[1:0] on a 32-bit bus). The lane mask serves as byte-write-enables (sub-word writes modify exactly their bytes) and valid-lane indicators (reads). This enables mixed-width data and byte-granular access on one bus, assuming natural alignment for clean lane groups. The sizes and their lane handling are foundational to how software and devices access data at their natural widths.

7. Industry Example

Trace the three sizes across a system's accesses on a 32-bit bus.

A processor accesses memory and peripherals of various widths.

• A word access — all four lanes. The processor reads a 32-bit instruction or integer from word-aligned memory using HSIZE=word. All four byte lanes carry the data — the full 32 bits. The streaming/bulk case (cache fills, DMA) also uses word beats. Word is the workhorse.
• A halfword access — two lanes. The processor reads a 16-bit value (a short integer, an ADC sample) using HSIZE=halfword. At a halfword-aligned address with addr[1]=0, lanes 0–1 carry the data; at addr[1]=1, lanes 2–3. The two active lanes carry the 16 bits; the other two are idle. The halfword access reads exactly the 16-bit value.
• A byte access — one lane. The processor writes a character to a byte-wide UART register, or a single byte into a buffer, using HSIZE=byte. The one active lane (selected by addr[1:0]) carries the byte; the byte-write-enable for that lane is asserted, so the write modifies exactly that byte. The other three bytes (if in a word-wide memory) are untouched.
• A sub-word write into memory. The processor writes one byte into a 32-bit word in memory (e.g., setting a flag byte). The byte-write-enable (from HSIZE=byte + the address) enables only that byte's lane, so the memory modifies one byte and preserves the other three. Without the byte-write-enable, this would corrupt the neighboring bytes — so the lane handling is essential for byte-granular writes.
• Mixed widths on one bus. Across these accesses, the same 32-bit bus carries word, halfword, and byte transfers to memory and peripherals of different widths — each access using exactly its lanes, routed by HSIZE + address. So the bus serves heterogeneous data widths, each at its natural width. The byte-wide UART, the 16-bit ADC, and the 32-bit memory all coexist, accessed at their widths.

The example shows the three sizes in practice: word for 32-bit data (all lanes), halfword for 16-bit data (two lanes), byte for single bytes (one lane), with the byte-write-enables enabling sub-word writes that modify exactly their bytes. The lane handling (HSIZE + address → lanes) routes each access correctly and isolates sub-word writes to their data — supporting mixed-width access on the common 32-bit bus.

8. Common Mistakes

9. Interview Insight

The lane usage of the common sizes is a practical interview check — knowing the size + address → lanes mapping and the byte-write-enable role is the signal.

The answer that lands gives the lane mapping and the byte-write-enable: "On a 32-bit bus with four byte lanes, a word transfer uses all four lanes — the full width. A halfword uses two adjacent lanes, selected by address bit 1: lanes 0–1 if it's 0, lanes 2–3 if it's 1. A byte uses one lane, selected by the low two address bits. So the size tells you how many lanes, and the low address bits tell you which lanes — the active lanes carry the transfer's valid data, and the others are unused for that transfer. For a write, the active-lane mask acts as byte-write-enables — so a byte write modifies exactly its byte in the word-wide memory, leaving the other three untouched; that's how byte-granular writes work without corrupting neighbors. For a read, the active lanes are the ones the slave drives with valid data. And accesses are naturally aligned, so the active lanes form a contiguous aligned group — a halfword uses an aligned pair, never lanes 1–2." The size + address → lanes mapping, the byte-write-enable role, and the natural-alignment note are the senior signals.

10. Practice Challenge

Reason from the lane usage.

1. Map the lanes. State which lanes a word, halfword, and byte use on a 32-bit bus, and what selects them.
2. A specific access. Give the active lane(s) for a byte at offset 1 and a halfword at offset 2.
3. Byte-write-enable. Explain how a byte write modifies one byte without disturbing the others.
4. Read the waveform. From Figure 2, identify the active lanes for each of the three transfers.
5. System need. Explain why sub-word sizes matter for byte-addressable memory.

11. Key Takeaways

• On a 32-bit bus, a word uses all 4 byte lanes, a halfword 2, and a byte 1 — the size determines how many lanes.
• The low address bits select which lanes — a halfword by addr[1] (lanes 0–1 or 2–3), a byte by addr[1:0] (one of the four). Size + address ⇒ active lanes.
• The active lanes carry valid data; the rest are unused for that transfer.
• For writes, the active-lane mask is the byte-write-enable — a sub-word write modifies exactly its bytes (a byte write touches one byte, leaving the others untouched). For reads, it's the valid-lane indicator.
• Sub-word sizes enable byte-granular access and mixed-width data — byte-wide registers, 16-bit data, byte writes into word memory — all on one bus, accessed at their natural width.
• Accesses are naturally aligned, so the active lanes form a contiguous aligned group (a halfword uses an aligned pair, never lanes 1–2).

12. What Comes Next

You now know how the common sizes use the bus lanes. The next chapters cover alignment and the general lane rule:

• 9.3 — Aligned Access (coming next) — the address-alignment requirement for each size.
• 9.4 / 9.5 (coming soon) — unaligned-access rules and the general lane-selection derivation.

To revisit the HSIZE encoding, see HSIZE Encoding; for the beat size in bursts, Beat Size. For the HSIZE signal, see HSIZE; for the write data it places on lanes, HWDATA & HRDATA. For the broader protocol map, see the AMBA family overview.