Tutorials
Protocols
Learn More
Transaction request
A transaction request is the control transfer that starts an AXI operation. The Manager sends one request on AW for a write transaction or one request on AR for a read transaction. That request gives the Subordinate enough information to know the first address, the number of data transfers, the maximum bytes per transfer, the address pattern, the transaction ID, and the attributes that affect memory type, protection, ordering, and system behavior.
Think of the request as a contract for the rest of the transaction. After the request is accepted, the participating components must complete the number of data transfers described by AxLEN. For writes, the Manager must provide the matching write data beats. For reads, the Subordinate must return the matching read data beats. If the request describes multiple transfers, the Subordinate or interconnect calculates the later transfer addresses from the first address, Size, Length, and Burst fields.
| Field | Signals | Meaning |
|---|---|---|
| Address | AWADDR, ARADDR | Address of the first transfer. |
| Size | AWSIZE, ARSIZE | Maximum bytes per data transfer. |
| Length | AWLEN, ARLEN | Number of transfers encoded as AxLEN + 1. |
| Burst | AWBURST, ARBURST | Address behavior between transfers. |
| ID | AWID, ARID | Transaction identifier used for ordering and response matching. |
| Attributes | AxCACHE, AxPROT, AxDOMAIN, AxQOS, and others | Memory, protection, coherency, and service metadata. |
The Ax prefix is used when the same rule applies to both write request and read request signals. For example, AxADDR means AWADDR for writes and ARADDR for reads.
Size attribute
Size indicates the maximum number of bytes in each data transfer. It must not exceed the data width of the interface. If Size is smaller than the data width, the transaction is a narrow transfer and only a subset of byte lanes is used on each beat.
For reads, Size tells how many data bytes must be valid in each read data transfer. For writes, Size tells which byte-lane window is permitted to be active; WSTRB then selects the bytes within that window that are actually written. This difference matters: Size defines the allowed transfer shape, while write strobes define byte validity on each write beat.
The Size attribute uses a 3-bit encoding:
AxSIZE | Bytes per transfer |
|---|---|
0b000 | 1 |
0b001 | 2 |
0b010 | 4 |
0b011 | 8 |
0b100 | 16 |
0b101 | 32 |
0b110 | 64 |
0b111 | 128 |
If an interface only supports full-width requests, AxSIZE can be omitted by interface property and tied to the value matching the data width. In normal tutorial examples, keeping AxSIZE visible is clearer because it explains full-width, narrow, and unaligned behavior.
Length attribute
Length defines the number of data transfers in the transaction. AxLEN encodes the number of transfers as AxLEN + 1, so AxLEN = 0 means one transfer and AxLEN = 3 means four transfers.
| Item | Rule |
|---|---|
| Transfer count | Length = AxLEN + 1 |
| Write obligation | The Manager must issue the number of W transfers described by Length. |
| Read obligation | The Subordinate must issue the number of R transfers described by Length. |
| WRAP Length | Only 2, 4, 8, or 16 transfers are allowed. |
| FIXED Length | Up to 16 transfers are allowed. |
| Early termination | Not supported for reads or writes. |
Size multiplied by Length gives the maximum number of bytes that the transaction can transfer. The actual number of bytes written can be lower when the start address is unaligned or when some WSTRB bits are deasserted. The number of beats, however, does not shrink.
Maximum number of bytes in a transaction
The maximum transaction byte count comes from the number of transfers multiplied by the bytes per transfer:
| Expression | Meaning |
|---|---|
SizeBytes = 2 ** AxSIZE | Maximum bytes per transfer. |
Length = AxLEN + 1 | Number of data transfers. |
MaximumBytes = SizeBytes * Length | Maximum byte capacity of the transaction. |
The protocol maximum is 4KB, and a transaction must not cross a 4KB boundary. Some interfaces use a smaller Max_Transaction_Bytes property such as 64, 128, 256, 512, 1024, or 2048 bytes. A Manager with a smaller maximum is compatible with a Subordinate that accepts a larger maximum, but a Manager that can issue larger transactions is not compatible with a Subordinate that only accepts smaller transactions.
Example: if AxSIZE = 0b010, each transfer can carry 4 bytes. If AxLEN = 3, the transaction has 4 transfers. The maximum transaction byte count is 4 * 4 = 16 bytes.
Burst attribute
Burst describes how the address changes from one transfer to the next. AXI defines three legal burst types:
AxBURST | Type | Meaning |
|---|---|---|
0b00 | FIXED | Same address for every transfer. Useful for FIFO-style access. |
0b01 | INCR | Address increments by Size. Common for normal sequential memory. |
0b10 | WRAP | Address increments then wraps at a Size x Length boundary. Common for cache lines. |
0b11 | Reserved | Not used for legal requests. |
| Burst type | Address behavior | Important restrictions |
|---|---|---|
INCR | Each transfer address increments by Size after the first transfer. | Most common burst type for sequential memory. |
WRAP | Address increments like INCR, then wraps back to the wrap boundary when the upper boundary is reached. | Start address must be aligned to Size; Length must be 2, 4, 8, or 16. |
FIXED | Every transfer uses the same address. | Byte lanes are constant across transfers; Length is limited to 16; mainly used for repeated access to one location such as a FIFO. |
For a wrapping burst, the wrap boundary is based on the total container size, Size * Length. A cache-line refill is the common mental model: the Manager can start at one word inside the line, continue upward, then wrap around to the lower part of the same line.
Transfer address
AxADDR is the address of the first transfer. For a multi-transfer transaction, later transfer addresses are derived from the first address and the burst shape.
| Term | Meaning |
|---|---|
| Start address | The value on AxADDR. |
| Aligned address | Start address rounded down to the nearest Size boundary. |
| Transfer address | Address used for a particular beat in the transaction. |
| Byte lanes | The data-bus byte positions used by that beat. |
| Container | The full address range covered by Size * Length, even if the first transfer is unaligned or some write strobes are low. |
For an aligned INCR burst, the address sequence is simple: first address, then first address plus Size, then plus Size again. For an unaligned first transfer, the first beat starts at AxADDR, and the following beats use aligned Size increments. This is why unaligned transfers are explained in a separate chapter.
For a WRAP burst, the transaction has a lower wrap boundary and an upper wrap boundary. When the next increment would reach the upper boundary, the address returns to the lower boundary. For a FIXED burst, the address does not change.
An AXI transaction must not cross a 4KB address boundary. This prevents one transaction from crossing between Subordinate address spaces and limits the address-generation support required in Subordinates and interconnect.
AXI does not support early termination of transactions. If a Manager starts a write transaction, it must provide the number of write data transfers indicated by Length. If it wants to avoid changing later bytes, it can deassert all write strobes for those write transfers. If a Manager starts a read transaction, it must complete the read response sequence even if it discards some read data.
4KB boundary
An AXI transaction must not cross a 4KB address boundary. A 4KB page boundary occurs when the lower 12 address bits roll over from 0xFFF to 0x000. For example, 0x0FFC is still in the page that starts at 0x0000, but 0x1000 is the first address in the next 4KB page.
This rule prevents one transaction from crossing between two Subordinate address regions. It also keeps address-generation logic practical, because a Subordinate or interconnect does not need to accept one request that spans two independent decode regions.
The rule applies to the transaction described by the request, not only to the bytes that software eventually cares about. Do not rely on deasserted WSTRB bits to make a crossing request legal. The request address, Size, Length, and Burst must describe a transaction that stays inside one 4KB page.
| Case | Example | Result |
|---|---|---|
| Ends exactly at boundary | AxADDR = 0x0FF0, 4-byte transfers, 4 transfers. Highest byte is 0x0FFF. | Legal |
| Crosses boundary | AxADDR = 0x0FF0, 4-byte transfers, 5 transfers. Includes byte 0x1000. | Illegal |
| Starts at boundary | AxADDR = 0x1000 and all bytes remain below 0x2000. | Legal |
| Uses write strobes to hide bytes | Request crosses 0x1000, but later WSTRB disables some bytes. | Still illegal |
For a simple aligned INCR burst, a useful check is: the first byte and the highest possible byte of the transaction must have the same address bits above bit 11. In other words, both addresses must belong to the same 4KB page. For unaligned or wrapping transactions, use the transaction container derived from the AXI address equations, because the legal byte-lane window can differ from the literal start address.
Regular transactions
AXI permits many legal combinations of Size, Length, Burst, and address alignment. Some systems use only a simpler subset called Regular transactions. This lets a Subordinate or bridge use simpler address and byte-lane logic.
A Regular transaction meets these criteria:
| Rule | Requirement |
|---|---|
| Length | 1, 2, 4, 8, or 16 transfers. |
| Size | If Length is greater than 1, Size is the same as the data channel width. |
| Burst | INCR or WRAP, not FIXED. |
| INCR address | Address is aligned to the transaction container. |
| WRAP address | Address is aligned to Size. |
The Regular_Transactions_Only property tells whether an interface only issues or only supports this subset. A Manager that only issues Regular transactions can connect to a Subordinate that supports all legal transactions or only Regular transactions. A Manager that can issue non-Regular transactions must not connect to a Subordinate that only supports Regular transactions, because a non-Regular request could lead to incorrect behavior.
AXI Protocol