AMBA AHB · Module 9

Narrow Transfers

AHB narrow transfers — accesses smaller than the data bus width that use only some byte lanes (leaving the rest idle) — their lane behavior, the bandwidth they waste, and when they're appropriate versus wasteful.

This closes Module 9 by generalizing a theme that has run through it: the narrow transfer. A narrow transfer is any access smaller than the data bus width — so it uses only some of the byte lanes (per the lane-selection rule, chapter 9.5) and leaves the rest idle. A byte or halfword on a 32-bit bus, or a word on a 64-bit bus, are narrow transfers. The key consequence: because the idle lanes carry no useful data, a narrow transfer moves less per beat than the bus could — wasted bandwidth. Narrow transfers are appropriate when the data is genuinely narrow (a byte/halfword register, a narrow peripheral, a sub-word field) — the idle lanes are unavoidable. They're wasteful when used for bulk data movement that could use the full bus width. So the closing lesson of the module ties size, lanes, and throughput together: match the transfer width to the data — narrow for narrow data, full-width for streaming.

1. What Is It?

A narrow transfer is an access whose size is smaller than the data bus width — so it uses only some of the byte lanes (the size-many active lanes, per chapter 9.5) and leaves the rest idle.

On different buses:

On a 32-bit bus: a byte (1 of 4 lanes) or a halfword (2 of 4 lanes) is narrow; a word (4 of 4) is full-width.
On a 64-bit bus: a byte (1 of 8), a halfword (2 of 8), or a word (4 of 8) is narrow; a doubleword (8 of 8) is full-width.

Figure 1 — a narrow transfer uses only a subset of the bus lanes (on a 64-bit bus, 8 lanes). A full-width (8-byte) transfer uses all 8 lanes. A narrow word (4-byte) uses 4 lanes, leaving 4 idle. A narrow byte (1-byte) uses 1 lane, leaving 7 idle. The idle lanes carry no useful data, so a narrow transfer moves less per beat than the bus could — wasted bandwidth.

So "narrow" is relative to the bus width: the same size can be full-width on one bus and narrow on a wider one. A word is full-width on a 32-bit bus but narrow on a 64-bit bus. What makes a transfer narrow is that its size is less than the bus width, so it doesn't use all the lanes. The active lanes are determined by the lane-selection rule (size + address, chapter 9.5); the rest are idle. And the idle lanes carry no data — a narrow transfer moves only its size's worth of data, even though the bus could carry more. This is the defining trait: a narrow transfer underutilizes the bus.

2. Why Does It Exist?

Narrow transfers exist because not all data is the full bus width — registers, fields, and devices are often narrower — so the bus must support sub-bus-width accesses, accepting that they use only some lanes.

A data bus has a fixed width (32, 64 bits), but the data accessed is often narrower: a byte-wide control register, a 16-bit field, a single byte within a word. These accesses are inherently narrower than the bus, so they can only use some lanes — the lanes for their bytes (chapter 9.5), leaving the rest idle. So narrow transfers exist because the bus must accommodate data smaller than its width. There's no way around the idle lanes for genuinely narrow data: a byte access on a 64-bit bus must leave 7 lanes idle (there's only 1 byte to move). So narrow transfers are a necessary capability — the bus serves narrow data by using a subset of lanes.

The reason the idle lanes are wasted bandwidth is that the bus could carry more data in that beat (the full width) but the narrow transfer only fills some lanes. So each narrow beat moves less than the bus's per-beat capacity — the idle lanes represent unused bandwidth. For genuinely narrow data, this waste is unavoidable (there's no more data to move) — it's not really "wasted" in the sense of a mistake; it's just that the data is narrow. But for bulk data that could be moved full-width, using narrow transfers is wasteful — it artificially underutilizes the bus when wider beats would move more. So the waste is acceptable for narrow data, problematic for bulk data. This is the crux: narrow transfers are fine when the data is narrow, wasteful when the data isn't.

The reason this matters for design is the throughput implication: bulk data movement should use the full bus width (full-width beats) to maximize bandwidth, reserving narrow transfers for genuinely narrow accesses. Using narrow transfers for bulk movement (e.g., copying a buffer byte-by-byte on a wide bus) wastes most of the bandwidth — moving 1/8 of the data per beat on a 64-bit bus instead of 8/8. So the design rule (echoing chapter 8.9) is to match the transfer width to the data: narrow for narrow, full-width for bulk. So narrow transfers exist as a necessary capability, and the design wisdom is to use them only when appropriate (narrow data), not for bulk movement. The existence is necessary; the wise use is the lesson.

3. Mental Model

Model a narrow transfer as sending a small parcel in a large truck — the truck (the bus) has lots of capacity, but a small parcel uses only part of it, leaving the rest empty; that's fine for a genuinely small parcel, but wasteful if you keep sending big shipments one small parcel at a time.

A delivery truck (the data bus) has a large cargo capacity (the bus width). When you send a small parcel (a narrow transfer — a byte, a halfword), it occupies only part of the truck, leaving the rest empty (idle lanes). For a genuinely small parcel (narrow data — a single register byte), that's fine — there's nothing more to send, so the empty space is unavoidable. But if you have a large shipment (bulk data) and you send it as many small parcels (narrow transfers), each truck trip is mostly empty — you waste most of the truck's capacity, needing far more trips than if you'd filled each truck (full-width beats). So you'd fill the truck (use full-width beats) for big shipments, and send small parcels (narrow transfers) only for genuinely small items. Match the load to the truck.

This captures narrow transfers: the truck's capacity = the bus width; a small parcel = a narrow transfer (some lanes used, rest empty); genuinely small parcel, empty space unavoidable = narrow data (the waste is fine); big shipment as small parcels = bulk movement with narrow transfers (wasteful — fill the truck instead); fill the truck = full-width beats. Small parcels for small items, full trucks for big shipments.

Watch narrow transfers using a subset of lanes:

Narrow transfers using a subset of lanes (64-bit bus)

3 cycles

Figure 2 — narrow transfers on a 64-bit bus (8 lanes). A doubleword (full-width) uses all 8 lanes — full bandwidth. A word (narrow) uses 4 lanes, leaving 4 idle — half the bandwidth. A byte (narrow) uses 1 lane, leaving 7 idle — an eighth of the bandwidth. The 'lanes used' row shows how much of the bus each transfer occupies; the idle lanes are wasted bandwidth for that beat.

The model's lesson: a narrow transfer fills only part of the bus — fine for narrow data, wasteful for bulk. In the waveform, the doubleword fills the 64-bit bus (full bandwidth), the word fills half, the byte an eighth. For genuinely narrow data, the idle lanes are unavoidable; for bulk data, use full-width beats to fill the bus.

4. Real Hardware Perspective

In hardware, a narrow transfer is just a transfer whose HSIZE is less than the bus width — the lane-selection logic (chapter 9.5) activates the size-many lanes and the rest are idle; there's no special "narrow" handling beyond the normal lane derivation.

A narrow transfer uses the same lane-selection logic as any transfer: from HSIZE (the size) and the low address bits (the offset), the lane decoder activates the size-many lanes starting at the offset (chapter 9.5). For a narrow transfer (size less than the bus width), this activates a subset of the lanes; the rest are idle (not driven with useful data for reads, not written for writes — their byte-write-enables are off). So "narrow" isn't a special case in hardware — it's the normal lane derivation producing a subset of active lanes. The hardware handles narrow transfers identically to full-width ones, just with fewer active lanes. So there's no extra "narrow transfer" logic; the lane decoder naturally handles it.

The idle lanes are simply inactive: for a write, their byte-write-enables (strobes) are off (so the downstream component doesn't write them, chapter 9.7); for a read, they're don't-care (the master ignores them, using only the active lanes). So the idle lanes carry no useful data — they're just not part of this transfer. The data that does move is on the active lanes (the size-many lanes). So a narrow transfer moves its size's worth of data on its lanes, with the idle lanes inactive. This is the hardware reality of "narrow": fewer active lanes, the rest inactive.

The throughput is determined by the active lanes per beat: a narrow transfer moves (size) bytes per beat, versus (bus width) bytes for a full-width transfer. So the per-beat bandwidth of a narrow transfer is (size / bus width) of the full bandwidth — a byte on a 64-bit bus is 1/8, a word is 1/2. So in hardware, the throughput cost of narrow transfers is concrete: they use a fraction of the bus's per-beat capacity. For sustained narrow transfers (e.g., a narrow burst), the bandwidth is correspondingly reduced. This is why full-width beats are preferred for bulk movement — they use the full per-beat capacity.

A hardware note on narrow bursts: a burst of narrow transfers (e.g., byte beats) is possible but moves only (size) bytes per beat — low bandwidth. So a narrow burst is rarely used for bulk movement (which would use full-width beats); narrow bursts make sense only when the data is narrow (e.g., streaming bytes to/from a byte-wide device). So even in bursts, the narrow-for-narrow-data, full-width-for-bulk rule applies. A bulk burst uses full-width beats; a narrow burst is for genuinely narrow streaming. So the hardware supports narrow bursts, but they're appropriate only for narrow data, consistent with the general rule.

5. System Architecture Perspective

At the system level, narrow transfers are the mechanism for accessing narrow data and devices on a wide bus — necessary and appropriate for genuinely narrow accesses — while the throughput discipline is to use full-width beats for bulk movement.

The narrow-data accommodation is the system need: a wide-bus system still has narrow data and devices (byte/halfword registers, narrow peripherals, sub-word fields), and narrow transfers let them be accessed at their natural width. So narrow transfers are essential for a wide-bus system to serve narrow accesses — without them, you couldn't cleanly access a byte register on a 64-bit bus. So narrow transfers are a necessary capability: the wide bus accommodates narrow data via narrow transfers (using a subset of lanes). This is the same mixed-width support as chapter 9.2, now framed as the narrow-vs-full-width distinction. The system serves both wide and narrow data on the same wide bus.

The throughput discipline is the architectural lesson: bulk data movement should use full-width beats (the full bus width) to maximize bandwidth, reserving narrow transfers for genuinely narrow accesses. A DMA copying a large buffer on a 64-bit bus should use doubleword (full-width) beats, not byte beats — byte beats would move 1/8 the data per beat, an 8x bandwidth loss. So the system's bulk movers (DMA, cache fills) use full-width beats; narrow transfers are for the control plane (narrow register accesses, chapter 8.2's control-vs-data-plane). So at the system level, the discipline is full-width for the data plane (bulk), narrow for the control plane (registers) — matching the transfer width to the data and the traffic type. This maximizes the bus's utilization for bulk movement while still serving narrow accesses.

Figure 3 — when narrow transfers are appropriate versus wasteful. Appropriate: genuinely narrow data — a byte/halfword register, a sub-word field, a narrow peripheral — where there's no wider data to move, so the idle lanes are unavoidable. Wasteful: bulk data movement with narrow beats, where the idle lanes waste bandwidth every beat and full-width beats should be used instead. Match the transfer width to the data: narrow for narrow data, full-width for streaming.

The bus-width choice interacts with narrow transfers: a wider bus gives more bandwidth for full-width (bulk) transfers but makes narrow transfers (fixed-size narrow data) use a smaller fraction of the bus (more idle lanes). So on a very wide bus, a byte access wastes even more lanes (1 of 16 on a 128-bit bus) — but that's fine, because narrow data is the control plane (low-bandwidth, latency-oriented), not where bandwidth matters. So the wide bus is chosen for bulk bandwidth (full-width beats), and the narrow accesses' larger idle fraction is acceptable (they're not bandwidth-critical). So the architecture optimizes the wide bus for bulk movement (full-width), accepting that narrow control accesses use a small fraction — which is the right trade, since bulk movement is where bandwidth matters. So narrow transfers and bus width together reflect the data-plane-vs-control-plane structure: wide bus + full-width beats for bulk data; narrow transfers (on the same wide bus) for narrow control accesses. This closes the size/alignment module by tying size, lanes, throughput, and the bus-width choice together.

6. Engineering Tradeoffs

Narrow transfers reflect the serve-narrow-data, full-width-for-bulk design.

Narrow transfers (necessary) vs full-width-only. Supporting narrow transfers lets narrow data/devices be accessed at their natural width (necessary), at the cost of idle lanes (lower per-beat bandwidth). A full-width-only bus couldn't serve narrow data cleanly. Narrow transfers are necessary; the idle lanes are unavoidable for narrow data.
Narrow for narrow data vs narrow for bulk. Narrow transfers are appropriate for genuinely narrow data (the idle lanes are unavoidable) but wasteful for bulk movement (idle lanes = lost bandwidth when full-width would work). Match the width to the data.
Full-width beats for bulk vs narrow beats. Bulk movement should use full-width beats (full per-beat bandwidth); narrow beats for bulk waste most of the bandwidth (size/bus-width fraction). Use full-width for streaming.
Wide bus (bulk bandwidth) vs narrow accesses' larger idle fraction. A wider bus gives more bulk bandwidth but makes narrow accesses use a smaller fraction (more idle lanes). Acceptable, since narrow accesses are the (non-bandwidth-critical) control plane.

The throughline: a narrow transfer is smaller than the bus width — it uses a subset of lanes (per the lane rule) and leaves the rest idle, moving less per beat (wasted bandwidth). It's necessary and appropriate for genuinely narrow data (byte/halfword registers, narrow peripherals) but wasteful for bulk movement, which should use full-width beats. The system discipline is full-width for the data plane (bulk), narrow for the control plane (registers) — matching the transfer width to the data. This closes the module by tying size, lanes, and throughput together.

Use full-width beats for bulk movement — narrow beats waste a large fraction of the bandwidth

The closing throughput rule for the module: for bulk data movement, use full-width beats (matching the bus width) — narrow beats waste a large fraction of the bandwidth. A narrow transfer uses only size/bus-width of the bus's per-beat capacity: a byte beat on a 64-bit bus moves 1 of 8 bytes per beat (1/8 bandwidth), a word beat 4 of 8 (1/2). So moving a large buffer with byte beats on a 64-bit bus would be 8x slower than with doubleword (full-width) beats — a huge, avoidable loss. So bulk movers (DMA, cache fills, streaming) must use full-width beats to fill the bus each beat. Reserve narrow transfers for genuinely narrow data — byte/halfword register accesses, narrow peripherals, sub-word fields — where there's no wider data to move and the idle lanes are unavoidable. This is the same lesson as the beat-size chapter (8.9): match the transfer width to the data. A common efficiency bug is using narrow beats for bulk movement (e.g., a misconfigured DMA), which cripples the bandwidth. Match the width: narrow for narrow data, full-width for bulk.

7. Industry Example

Trace narrow vs full-width transfers in a wide-bus system.

A system with a 64-bit AHB has a DMA engine, a CPU with caches, and narrow peripherals.

DMA bulk copy — full-width (doubleword) beats. The DMA copies a large buffer using doubleword (8-byte) beats — the full 64-bit width. Each beat uses all 8 lanes, moving 8 bytes — full bandwidth. This is the correct, efficient choice for bulk movement: fill the bus each beat. The DMA streams at the bus's peak bandwidth.
Cache line fill — full-width beats. The CPU fills cache lines using doubleword beats (full-width) — maximum bandwidth for the fill. Again, full-width for the data plane.
A byte-wide peripheral register — narrow (byte) transfer. The CPU writes a byte-wide control register on a peripheral using a byte transfer — 1 of 8 lanes used, 7 idle. This is a narrow transfer, but it's appropriate: the register is genuinely 1 byte, so there's no more data to move; the idle lanes are unavoidable. The byte access is correct here, even though it uses 1/8 of the bus. Narrow data → narrow transfer.
A 16-bit field — narrow (halfword) transfer. Accessing a 16-bit field uses a halfword transfer — 2 of 8 lanes. Narrow, but appropriate (the data is 16 bits).
The discipline. The DMA and cache fills (data plane, bulk) use full-width beats; the peripheral register accesses (control plane, narrow) use narrow transfers. So the system matches the transfer width to the data: full-width for bulk, narrow for narrow accesses. The narrow transfers' idle lanes are fine (narrow data), and the bulk movers use the full bus.
A bug avoided. Had the DMA been (mistakenly) configured for byte beats, it would move 1/8 the data per beat — an 8x bandwidth loss on the 64-bit bus, crippling the copy. Using doubleword beats avoids this. So the throughput discipline (full-width for bulk) is what keeps the DMA fast.

The example shows the narrow-vs-full-width discipline: full-width (doubleword) beats for bulk movement (DMA, cache fills — full bandwidth), and narrow transfers (byte/halfword) for genuinely narrow data (peripheral registers, fields — idle lanes unavoidable but fine). Matching the width to the data keeps bulk movement fast and serves narrow accesses correctly. The misconfigured-narrow-DMA bug shows the cost of getting it wrong.

8. Common Mistakes

Narrow-transfer misconceptions

"Narrow is an absolute size." No — "narrow" is relative to the bus width: a word is full-width on a 32-bit bus but narrow on a 64-bit bus. Narrow = smaller than the bus.
"Narrow transfers are always wasteful." No — for genuinely narrow data (a byte register), the idle lanes are unavoidable (no more data to move). Narrow is wasteful only when used for bulk movement that could be full-width.
"Narrow transfers need special handling." No — they use the normal lane-selection logic (chapter 9.5), just activating fewer lanes. No special "narrow" hardware.
"Use narrow beats to be safe / simple." No — for bulk movement, narrow beats waste a large fraction of the bandwidth (size/bus-width). Use full-width beats for bulk.
"The idle lanes carry data." No — the idle lanes are inactive (write strobes off, read lanes don't-care). Only the active (size-many) lanes carry the transfer's data.
"A wider bus is always better for all accesses." A wider bus helps bulk (full-width) accesses, but narrow accesses use a smaller fraction of it (more idle lanes). That's fine (narrow accesses aren't bandwidth-critical), but a wider bus doesn't speed up a fixed-size narrow access.

9. Interview Insight

Narrow transfers are a synthesizing interview check — the relative-to-bus-width definition, the bandwidth cost, and the match-the-width discipline are the signals.

Figure 4 — a strong answer in one card: a narrow transfer is smaller than the bus width, so it uses only some byte lanes (per the lane rule) and leaves the rest idle, moving less per beat (wasted bandwidth); it's appropriate for genuinely narrow data (byte/halfword registers, narrow peripherals) but wasteful for bulk movement, which should use full-width beats. The senior point: match the transfer width to the data — narrow for narrow data, full-width for streaming.

The answer that lands defines narrow relatively and gives the discipline: "A narrow transfer is one whose size is smaller than the data bus width — so by the lane-selection rule, it uses only some of the byte lanes and leaves the rest idle. 'Narrow' is relative to the bus: a word is full-width on a 32-bit bus but narrow on a 64-bit bus. The key consequence is bandwidth: because the idle lanes carry no data, a narrow transfer moves only size/bus-width of the bus's per-beat capacity — a byte on a 64-bit bus is 1/8, a word is 1/2. For genuinely narrow data — a byte or halfword register, a narrow peripheral — the idle lanes are unavoidable, so a narrow transfer is appropriate. But for bulk data movement, narrow transfers are wasteful — moving a buffer with byte beats on a 64-bit bus is 8x slower than with full-width beats. So the discipline is to match the transfer width to the data: full-width beats for bulk movement (the data plane), narrow transfers for genuinely narrow accesses (the control plane). In hardware it's just the normal lane logic with fewer active lanes — no special handling." The relative definition, the bandwidth fraction, and the match-the-width discipline are the senior signals.

🔍 The discriminator: narrow is relative to the bus, and the waste is fine for narrow data but not for bulk

The discriminator on narrow transfers is whether you define "narrow" relative to the bus width and correctly judge when the waste matters. A weak answer says "a narrow transfer is small." A strong answer: a narrow transfer is one smaller than the bus width (so "narrow" is relative — a word is full-width on 32-bit but narrow on 64-bit), using only the size-many active lanes (per the lane rule, chapter 9.5) and leaving the rest idle. The senior insight is the nuanced judgment about the wasted bandwidth: for genuinely narrow data (a byte register, a narrow peripheral), the idle lanes are unavoidable — there's no more data to move — so the narrow transfer is appropriate, not wasteful; but for bulk data movement, narrow transfers are wasteful (the idle lanes are lost bandwidth when full-width beats would move more — size/bus-width fraction, e.g., 1/8 for byte beats on a 64-bit bus). So the discipline is to match the transfer width to the data: full-width beats for bulk (the data plane), narrow transfers for genuinely narrow accesses (the control plane). The flourish is noting that in hardware it's just the normal lane derivation with fewer active lanes (no special handling), and that this ties together the whole module (size → lanes → throughput). A candidate who defines narrow relatively, judges the waste correctly (fine for narrow data, costly for bulk), and gives the match-the-width discipline demonstrates they've synthesized the size/alignment module — beyond "narrow means small."

10. Practice Challenge

Reason from narrow transfers.

Define it. Explain what makes a transfer "narrow" and why it's relative to the bus width.
Bandwidth. Give the fraction of bandwidth a byte, halfword, and word use on a 64-bit bus.
Read the waveform. From Figure 2, identify which transfers are narrow and their bandwidth.
Appropriate vs wasteful. Give an example where a narrow transfer is appropriate and one where it's wasteful.
The discipline. State the rule for matching transfer width to data, and why bulk movement uses full-width beats.

11. Key Takeaways

A narrow transfer is smaller than the data bus width — it uses only the size-many active lanes (per the lane rule) and leaves the rest idle. "Narrow" is relative to the bus.
The idle lanes carry no data, so a narrow transfer moves only size/bus-width of the bus's per-beat bandwidth (a byte on a 64-bit bus = 1/8, a word = 1/2).
Narrow transfers are appropriate for genuinely narrow data (byte/halfword registers, narrow peripherals, sub-word fields) — the idle lanes are unavoidable.
They're wasteful for bulk movement — narrow beats for bulk data waste a large fraction of the bandwidth; bulk movement should use full-width beats.
In hardware, narrow is the normal lane derivation with fewer active lanes — no special handling; the idle lanes are inactive (write strobes off, read lanes don't-care).
The discipline: match the transfer width to the data — full-width for the data plane (bulk), narrow for the control plane (registers) — tying together size, lanes, and throughput.

12. What Comes Next

This completes Module 9 — Transfer Size and Alignment. You now understand the HSIZE encoding, the byte/halfword/word sizes and their lanes, alignment and the unaligned prohibition, the general lane-selection rule, endianness, write strobes in bridges, and narrow transfers. The next module turns to multi-master operation:

Module 10 — Arbitration & Multi-Master AHB (coming next) — how multiple masters share the bus via arbitration (HBUSREQ, HGRANT, HMASTER), arbitration schemes, and multi-master coordination.

To revisit the size and lane topics, see HSIZE Encoding, Byte, Halfword & Word Transfers, Lane Selection, and Beat Size. For the broader protocol map, see the AMBA family overview.