AMBA AXI · Module 7

Narrow & Unaligned Transfers

AXI narrow transfers (AxSIZE below the bus width, where active byte lanes rotate with the address) and unaligned start addresses (which produce a partial first beat) — the byte-lane mapping, why they matter, and how to handle them.

Two situations make an AXI burst's byte handling more intricate than "every beat fills the bus": narrow transfers (where AxSIZE is smaller than the data bus, so each beat uses only some byte lanes) and unaligned starts (where AxADDR isn't aligned to the transfer size, so the first beat is partial). Both are legal and common, and both come down to one question per beat: which byte lanes carry valid data? This chapter answers that — the lane rotation of narrow transfers, the partial first beat of unaligned starts, and the address-to-lane mapping that governs both. It's the conceptual setup for the strobe-progression detail in Chapter 7.8.

1. Narrow Transfers — Fewer Lanes, Rotating

A narrow transfer has AxSIZE smaller than the data bus width, so Number_Bytes = 2^AxSIZE is less than the bus's byte count. Each beat moves only Number_Bytes bytes, occupying just some of the byte lanes — and because INCR's address increments by Number_Bytes each beat, which lanes are active rotates as the burst proceeds.

Example: a 32-bit bus (4 byte lanes) doing 1 byte/beat (AxSIZE = 0), INCR from 0x00. Beat 0 → address 0x00 → lane 0; beat 1 → 0x01 → lane 1; beat 2 → 0x02 → lane 2; beat 3 → 0x03 → lane 3. The single active lane walks across the bus. With 2 bytes/beat (AxSIZE = 1) it would alternate lanes [1:0] then [3:2]. The active lane(s) are always those the current address selects within the bus word.

Figure 1 — a narrow transfer (1 byte/beat on a 4-lane / 32-bit bus, INCR from 0x00). Each beat uses a single byte lane, and the active lane rotates with the address: beat 0 → lane 0, beat 1 → lane 1, and so on. Narrow transfers use a subset of the bus each beat; the subset shifts as the address advances.

2. Unaligned Transfers — The Partial First Beat

An unaligned transfer has AxADDR not aligned to the transfer size. From the addressing rules (Chapter 7.5), beat 1 uses Start_Address (the unaligned address) while beats 2+ use Aligned_Address. The consequence: the first beat is partial — it transfers only the bytes from the unaligned offset up to the next size-aligned boundary, using only the upper byte lanes from that offset. After that, the progression snaps to aligned addresses and every later beat is a full Number_Bytes transfer.

Example: a 4-byte/beat INCR from 0x02 on a 32-bit bus. Aligned_Address = 0x00. Beat 0 is at 0x02 but transfers only bytes at lanes 2–3 (the bytes 0x02–0x03, up to the 4-byte boundary at 0x04); beat 1 is at 0x04 (full, lanes 0–3); and so on. So the unaligned offset is "consumed" by a partial leading beat, after which the burst is aligned.

Figure 2 — an unaligned start (4 bytes/beat INCR from 0x02 on a 32-bit bus). Beat 0 is partial: it transfers only lanes 2–3 (bytes 0x02–0x03, up to the aligned boundary 0x04). Beats 1+ are aligned and full-width. The unaligned offset is absorbed by the partial first beat; the rest of the burst is regular.

3. The Byte-Lane Mapping

Both behaviors come from one mapping: which byte lanes a beat uses are determined by its address modulo the bus width and its transfer size. For a beat at Address on a bus of Data_Bus_Bytes:

lower byte lane = Address − (INT(Address / Data_Bus_Bytes) × Data_Bus_Bytes) — i.e., Address mod Data_Bus_Bytes

the beat occupies Number_Bytes lanes starting there (clipped to the aligned boundary for a partial beat).

So: the address mod bus width picks the starting lane; the transfer size sets how many lanes; and alignment determines whether the beat is full or clipped. Narrow transfers make Number_Bytes small (few lanes, rotating as the address steps); unaligned starts make the first beat's lane span start mid-word and clip at the boundary. Reads work identically — the subordinate places valid bytes on the lanes the address selects, and the manager takes them from there.

Figure 3 — the address-to-lane mapping. The starting byte lane is Address mod Data_Bus_Bytes; the number of lanes is Number_Bytes (2^AxSIZE); alignment clips a partial first beat. Narrow → few lanes that rotate with the address; unaligned → first beat starts mid-word. One rule explains both.

4. A Narrow Transfer on the Wire

A narrow write — 1 byte/beat on a 32-bit bus, INCR from 0x00 — shows the active lane (via WSTRB) walking across the bus beat by beat:

narrow-transfer — 1 byte/beat INCR write, WSTRB walking across lanes

6 cycles

Figure 4 — narrow-transfer: a 1-byte/beat (AxSIZE=0) INCR write on a 32-bit bus from 0x00. WSTRB asserts a single lane that rotates each beat — 0001, 0010, 0100, 1000 — as the address steps 0x00 → 0x03. Only one byte lane is live per beat; the live lane tracks the address. (Strobe progression is detailed in Chapter 7.8.)

5. Why They Matter — and the Efficiency Cost

Narrow and unaligned transfers exist because real systems need them: a narrow transfer arises when a master or peripheral has a data path smaller than the interconnect's, or when software does sub-word accesses (a byte/halfword store); an unaligned transfer arises whenever a buffer or structure isn't size-aligned (common with packed data, software memcpy of arbitrary pointers, or byte-oriented protocols).

Both are legal but carry an efficiency cost: a narrow transfer uses only part of the bus each beat, wasting bandwidth (a 1-byte/beat burst on a 64-bit bus uses 1/8 of the available width); an unaligned start spends a partial beat on the leading remainder. High-performance paths therefore prefer aligned, full-width transfers — but the protocol fully supports the narrow/unaligned cases, and the hardware must handle them correctly, because they will occur.

6. Common Misconceptions

Myths to unlearn

"Narrow transfers always use the low byte lanes." No — the active lanes are Address mod Data_Bus_Bytes based, so they rotate as the address increments. A 1-byte/beat burst walks lane 0, 1, 2, 3, …
"Unaligned means every beat is partial." Only the first beat is partial (it absorbs the unaligned offset). Beats 2+ use Aligned_Address and are full-width.
"Narrow and unaligned are the same thing." They're distinct: narrow = small AxSIZE (fewer lanes per beat); unaligned = AxADDR not size-aligned (partial first beat). They can occur separately or together.
"A narrow transfer changes the increment." The address still increments by Number_Bytes = 2^AxSIZE per beat — that's just a small step. The increment rule (Chapter 7.3) is unchanged; only fewer lanes are used.
"WRAP supports unaligned starts." No — WRAP requires a size-aligned start. Only INCR (and the degenerate FIXED) allow unaligned addresses.
"The subordinate can ignore which lanes are active." It cannot — it must place/consume bytes on exactly the lanes the address selects (and honor WSTRB), or data lands in the wrong byte positions.

7. Debugging Insight

🔍 Debugging insight — wrong-lane and partial-beat errors put bytes in the wrong place

Narrow/unaligned bugs manifest as bytes in the wrong byte positions, not bus errors:

Narrow-transfer data in the wrong lanes / byte-swapped? The implementation isn't rotating the active lane with the address — it's using a fixed lane (often the low one) every beat. Check that the active lane tracks Address mod Data_Bus_Bytes: beat n's byte should be on the lane its address selects, not always lane 0.
Unaligned access corrupts the byte just before the start, or drops the leading bytes? The partial first beat is mishandled — either it wrote full-width (clobbering bytes below the start offset) or it used Aligned_Address for beat 1 (placing the leading bytes wrong). Beat 1 must be at Start_Address and clipped to the boundary.
Everything shifted by a constant byte offset? The lane mapping used the wrong Data_Bus_Bytes (wrong bus width) so Address mod width is off.
Data correct on an aligned/full-width run but wrong on sub-word or odd-address accesses? The narrow/unaligned path is exercised only by those accesses — the bug is specific to the partial/rotating-lane logic, which aligned full-width traffic never hits.

The diagnostic: for each beat, compute its address, then Address mod Data_Bus_Bytes for the starting lane and Number_Bytes for the count, and confirm the data sits on exactly those lanes. Wrong-lane placement is the universal symptom; the fix is making lane selection address-driven and clipping partial beats correctly.

8. Verification Insight

✅ Verification insight — byte-accurate, lane-aware checking is mandatory

These cases are exactly where a byte-accurate, lane-aware scoreboard earns its keep — a word-granular check passes wrong-lane and partial-beat bugs. For each beat, the reference model computes the active byte lanes from Address mod Data_Bus_Bytes and Number_Bytes (clipping the partial first beat at the aligned boundary), and asserts the data/strobes appear on exactly those lanes and nowhere else. Verify both narrow (active lane(s) rotate correctly as the address steps across the bus word) and unaligned (the first beat is partial at the right lanes; masked bytes below the start offset are untouched; beats 2+ are full).

Coverage must sweep: every AxSIZE from 1 byte to full width on the given bus; start offsets at every byte position within a bus word (so the first-beat lane span starts at each lane); narrow + unaligned combined; and the rotation across a full bus word for the narrowest size. The most productive directed tests are the narrowest transfer (single lane walking all positions) and the maximally-unaligned start (offset = bus width − 1, smallest leading beat). Because the active lanes drive WSTRB, this dovetails with the strobe-progression checks of Chapter 7.8 — verify them together, since a lane-mapping error and a strobe error are two views of the same defect.

9. Interview Questions

10. Summary

Narrow and unaligned transfers are about one thing: which byte lanes a beat uses. A narrow transfer (AxSIZE below the bus width) moves only 2^AxSIZE bytes per beat, occupying a subset of lanes that rotates as the address increments (1 byte/beat on a 32-bit bus walks lanes 0→1→2→3). An unaligned start (AxADDR not size-aligned) makes the first beat partial — it transfers only from the offset up to the aligned boundary, on the upper lanes — after which beats snap to Aligned_Address and run full-width. Both follow the single mapping: starting lane = Address mod Data_Bus_Bytes, count = Number_Bytes, clipped if partial.

They're legal and necessary (narrow peripherals, sub-word accesses, unaligned buffers) but cost bandwidth, so high-performance paths prefer aligned full-width. Their bugs are wrong-lane / partial-beat errors — bytes in the wrong positions, visible only on sub-word/odd-address accesses — and the cure for both debug and verification is a byte-accurate, lane-aware model that places each beat's bytes on exactly the address-selected lanes. Next: strobe behavior in bursts — how WSTRB concretely evolves across these narrow and unaligned beats, completing the picture.

11. What Comes Next

You've got the lane mechanics; next, the strobes that express them:

7.8 — Strobe Behavior in Bursts (coming next) — how WSTRB evolves beat-by-beat across narrow and unaligned bursts, tying lanes, addresses, and strobes together.

Previous: 7.6 — The 4KB Boundary Rule. Related: 7.5 — Burst Address Calculation for the per-beat addresses, and 6.7 — WSTRB Write Strobes for the strobe basics. For the broader protocol catalog, see the AMBA family overview doc.