Unaligned transfers

AXI supports unaligned transfers. An access is unaligned when its start address is not naturally aligned to the number of bytes in each transfer. For example, a 32-bit transfer has a natural 4-byte boundary, so addresses 0x1000, 0x1004, and 0x1008 are aligned, but address 0x1002 is unaligned.

Unaligned transfers are important because software often works with packed data structures, byte streams, headers, or payloads that do not always begin on a word boundary. AXI handles this with the normal address, Size, Burst, and byte-lane rules. It does not add a separate unaligned-transfer channel.

For transfers wider than one byte, the first transfer of an incrementing transaction can be partial because the start address might fall in the middle of the natural transfer window. After that first transfer, the next transfer uses the next aligned Size boundary. The transaction Length still counts transfers, not bytes, so an unaligned first transfer can move fewer actual bytes than Size * Length.

Concept	Meaning
Natural alignment	The start address is divisible by the transfer size in bytes.
Unaligned start	The start address is not divisible by the transfer size in bytes.
Aligned address	The start address rounded down to the nearest transfer-size boundary.
First transfer	Can use only the byte lanes from the unaligned start address up to the end of the natural transfer window.
Later `INCR` transfers	Move to aligned Size increments after the first transfer.
Write strobes	`WSTRB` identifies the byte lanes that are actually written.

A Manager can indicate an unaligned write start by using the low-order address bits, by using byte lane strobes with an aligned address, or by using both consistently. The key rule is that the address information and WSTRB must describe the same byte-lane intent. For reads, there is no read strobe signal, so the request address and Size determine which returned byte lanes are meaningful.

The Subordinate is not required to take special action merely because an access is unaligned. It observes the request and byte-lane information and completes the transaction according to its supported behavior.

Figure compares 32-bit transfers on a 32-bit data channel. Each row is one transfer, and the shaded cells in the specification figure are byte lanes that are not transferred.

The aligned example starts at address 0x00. Because the transfer size is 32 bits, each transfer normally covers four byte addresses. The four-beat incrementing transaction therefore transfers 0x00-0x03, then 0x04-0x07, then 0x08-0x0B, and finally 0x0C-0x0F.

The unaligned examples show what changes when the start address is not on a 4-byte boundary. If the start address is 0x01, the first transfer cannot include byte 0x00; it begins at 0x01 and reaches only to the end of that 32-bit lane window at 0x03. The next transfer then starts at the aligned address 0x04. If the start address is 0x07, the first transfer contains only byte 0x07, because bytes 0x04, 0x05, and 0x06 are before the requested start address and are not transferred.

Start address	Length	First transfer	Later transfers	Key point
`0x00`	4	`0x00-0x03`	`0x04-0x0F`	Fully aligned baseline.
`0x01`	4	`0x01-0x03`	`0x04-0x0F`	First transfer is partial.
`0x01`	5	`0x01-0x03`	`0x04-0x13`	Length counts beats; actual bytes can be less than `Size * Length`.
`0x07`	5	`0x07` only	`0x08-0x17`	A highly unaligned first beat can carry only one valid byte.

For writes, the first transfer must have WSTRB deasserted for the byte lanes that are not transferred. For reads, the Manager must treat only the requested byte lanes as meaningful.

Above figure uses 32-bit transfers on a 64-bit data channel. This combines two ideas: the transfer is narrow relative to the bus, and the start address can also be unaligned. Each transfer still moves at most four bytes because the transfer size is 32 bits, even though the data bus has eight byte lanes.

For an aligned start at address 0x00, the active 32-bit region moves across the 64-bit bus as the address increments. One transfer can occupy the lower half of the 64-bit data channel, and the next transfer can occupy the upper half. When the address moves to the next 64-bit word, the pattern continues.

For an unaligned start at address 0x07, the first transfer contains only byte 0x07. The earlier byte lanes in that natural 32-bit transfer window are not part of the request. The following transfers then continue from the aligned address 0x08, so the next full 32-bit transfer uses bytes 0x08-0x0B, then 0x0C-0x0F, and so on.

Start address	Length	First transfer	Later transfers	Key point
`0x00`	4	`0x00-0x03`	`0x04-0x0F`	32-bit beats use half of the 64-bit bus at a time.
`0x07`	4	`0x07` only	`0x08-0x13`	Unaligned first beat is partial; later beats are aligned 32-bit transfers.
`0x07`	5	`0x07` only	`0x08-0x17`	More beats extend the burst, but the first beat remains partial.

This figure is useful for students because it shows that “unaligned” and “narrow” are different concepts. A 32-bit transfer on a 64-bit data channel is narrow. Starting that 32-bit transfer at 0x07 also makes the first transfer unaligned.

Above figure shows an aligned 32-bit wrapping transaction on a 64-bit data channel. The start address is 0x04, the transfer size is 32 bits, and the burst length is four transfers. The start address is aligned to the 4-byte transfer size, so this is not an unaligned-start example. It is included with the byte-lane examples because it uses the same active-lane selection rules.

For a four-beat wrapping burst with 4 bytes per beat, the wrap container is 4 * 4 = 16 bytes. Starting at 0x04, the address sequence is:

Transfer	Address range	What happens
1st	`0x04-0x07`	Starts in the upper half of the first 64-bit word.
2nd	`0x08-0x0B`	Moves to the lower half of the next 64-bit word.
3rd	`0x0C-0x0F`	Moves to the upper half of that 64-bit word.
4th	`0x00-0x03`	Wraps back to the start of the 16-byte container.

The useful lesson is that wrapping changes the address sequence, not the meaning of byte lanes. The active lanes are still selected by address and transfer size. The wrap only decides where the next address goes after the upper boundary of the wrap container is reached.

Unaligned transfer checks

For RTL and verification, unaligned transfers are a common source of byte-lane bugs. The design should compute the legal byte-lane window from address and Size, then compare write strobes against that window.

Check	Why it matters
Do not assume `AxADDR` low bits are zero.	Legal AXI requests can start at an unaligned byte address.
First `INCR` transfer can be partial.	Actual transferred bytes can be lower than `Size * Length`.
Later `INCR` transfers align to Size.	Address generation must not keep repeating the first unaligned offset.
`WSTRB` must not enable lanes outside the legal window.	Otherwise a write can corrupt bytes before the requested start address.
Read data inactive lanes must be ignored.	Only the byte lanes selected by address and Size are part of the transfer.

AXI Protocol