Tutorials

Protocols

Learn More

Contents hide

1 Transaction IDs and Ordering

1.1 Transaction identifiers

1.1.1 Transaction ID signals

1.1.2 Interconnect use of transaction identifiers

1.2 Request ordering

1.2.1 Response before the endpoint

1.2.2 Write data and response ordering

1.3 Read data ordering

1.3.1 Read data interleaving

1.3.2 Read data chunking

1.3.3 Rules

Transaction IDs and Ordering

AXI IDs let a Manager issue multiple outstanding transactions and let a Subordinate or Interconnect return responses to the correct transaction stream. IDs are also the boundary for many ordering guarantees.

Transaction identifiers

Transaction identifiers are carried on request and response channels so a component can have more than one transaction outstanding and still match each response to the correct request stream.

Transaction ID signals

Channel	ID signal	Purpose
`AW`	`AWID`	Write request ID.
`B`	`BID`	Write response ID. Must match the request being completed.
`AR`	`ARID`	Read request ID.
`R`	`RID`	Read data ID. Must match the request being completed.

Interconnect use of transaction identifiers

An interconnect can append Manager-port bits to IDs so that different Managers using the same local ID value remain unique at downstream Subordinates. On response return, the interconnect uses those extra bits to route the response and strips them before presenting the ID back to the Manager.

Request ordering

AXI is neither fully ordered nor fully unordered. It is ordered where the protocol says it is ordered, and flexible elsewhere.

Situation	Ordering rule
Same ID to same ordered target or region	Responses must preserve required order.
Different IDs	Completion can be out of order when the target and interconnect support it.
Same ID targeting different Subordinates	Interconnect must return responses in request order when required by the same-ID rules.
Reads with different IDs	Read data can be interleaved if supported.
Writes	Write data is normally issued in write request order, with a Resource Plane exception for credited transport.

AXI defines observation and completion separately. A write completion response can imply different visibility depending on memory type and buffering. For example, Device Non-bufferable writes require the response from the final destination, while Bufferable writes can receive a response from an intermediate point once observability requirements are met.

Response before the endpoint

An intermediate component can sometimes send an early read or write response. When it does, it becomes responsible for maintaining the ordering and observability obligations of that transaction until the downstream transaction is complete.

For an early write response:

The component must not discard data before it has propagated the write downstream.
It must preserve ID ordering.
Subsequent transactions to overlapping memory or the same peripheral region must be ordered correctly behind the write that received the early response.

Write data and response ordering

A Manager must issue write data in the same order it issues write requests. With credited transport, this rule applies per Resource Plane. Therefore, write data for transactions using different Resource Planes can be interleaved or appear out of request order with respect to each other.

Figure is useful because it shows the credited-transport exception to the simple write-data ordering rule. Without multiple Resource Planes, the write data channel follows the write request order. With multiple Resource Planes, the write data ordering rule is applied independently inside each Resource Plane.

In the figure, the write requests are issued in this order:

Request order	`AWID`	`AWRP`	Meaning
1	`ID0`	`RP0`	First write transaction, assigned to Resource Plane 0.
2	`ID1`	`RP1`	Second write transaction, assigned to Resource Plane 1.
3	`ID2`	`RP0`	Third write transaction, also assigned to Resource Plane 0.

The write data transfers then use the WRP signal to identify which Resource Plane each data beat belongs to. Figure A5.1 shows data for RP1 being sent before data for RP0. That is legal because ID1 is on RP1, while ID0 is on RP0. The Manager is not violating write data order because the ordering rule is checked separately for each Resource Plane.

The important reading is:

What the figure shows	Why it is legal
Data for `ID1/RP1` can appear before data for `ID0/RP0`.	The transactions use different Resource Planes.
Data for `ID1/RP1` can be interleaved between data transfers for `ID0/RP0` or `ID2/RP0`.	Interleaving is allowed across different Resource Planes.
Data for `ID0/RP0` and `ID2/RP0` must preserve their Resource Plane order.	They share `RP0`, so the normal write-data ordering rule still applies within that plane.
`AWRP` and `WRP` must agree for a transaction.	The write request and write data for the same transaction belong to the same Resource Plane.

Do not read this figure as saying that write data can be arbitrarily reordered. It only permits reordering or interleaving across different Resource Planes. Within one Resource Plane, the Manager still sends write data in the order of the write requests for that Resource Plane.

The Subordinate must ensure that BID matches the AWID of the completed request. The interconnect must preserve same-ID write response order even when same-ID writes target different Subordinates.

Read data ordering

Read data ordering is controlled by the read transaction ID. The AR request carries ARID, and every returned R transfer carries RID. The Subordinate must return RID equal to the ARID of the request being completed, so the Manager can match each data beat to the correct outstanding read.

If several read transactions use the same ARID, the Manager must see their read data in request order. This rule still matters when the same-ID requests target different Subordinates through an interconnect. The interconnect must route and sequence the returned data so the Manager receives same-ID read responses in the required order.

Situation	Read data ordering rule
Same `ARID`	Read data for later same-ID transactions must not overtake earlier same-ID transactions.
Different `ARID` values	Read data can be returned out of request order when the interface supports it.
Same `ARID`, different Subordinates	The interconnect must return the data to the Manager in request order.
Every read data beat	`RID` must match the `ARID` of the request being completed.
Final beat	`RLAST` marks the final transfer of that read transaction.

The read data reordering depth is the maximum number of accepted read requests for which a Subordinate might return data out of request order. A Subordinate that always returns read data in the same order as requests has a reordering depth of one. This is a static design characteristic of the Subordinate; AXI does not provide a runtime mechanism for a Manager to discover it dynamically.

Read data interleaving

Read data interleaving means that beats from different read transactions can appear mixed together on the R channel. This is only allowed for transactions with different ID values. For example, the Subordinate can return one beat for RID = 2, then one beat for RID = 7, then another beat for RID = 2, as long as each transaction’s own beat count, RRESP, and RLAST remain correct.

The Read_Interleaving_Disabled property tells whether an interface can use this behavior.

`Read_Interleaving_Disabled`	Default	Meaning
`True`	No	A Manager cannot receive interleaved read data, or a Subordinate guarantees it will not interleave read data.
`False`	Yes	A Manager can receive interleaved read data, or a Subordinate might interleave read data from transactions with different `ARID` values.

For design and verification, the important rule is that any Manager issuing reads with different IDs must be prepared to track multiple active read streams unless the system configuration guarantees that interleaving is disabled.

Signal/check	What to verify
`RID`	Each read beat maps to the correct outstanding `ARID`.
Per-ID beat counter	Each ID stream counts its own returned beats.
`RLAST`	Asserted on the final beat of the corresponding transaction, not merely on the final beat currently visible on the bus.
`RRESP`	Checked per returned beat and per `RID`.

Read data chunking

Read data chunking is an optional feature that lets a Subordinate return read data in reorderable 128-bit chunks within a transaction. It is useful for wide data channels and cache-line traffic because the Subordinate does not always have to wait until it can return the data in natural order.

Chunking is not the same as ordinary read interleaving. Interleaving mixes data from different read transactions. Chunking reorders pieces inside one read transaction.

Feature	Reorders what?	Main identifier
Read interleaving	Beats from different read transactions	`RID`
Read data chunking	128-bit chunks inside one read transaction	`RCHUNKNUM` and `RCHUNKSTRB`

The Read_Data_Chunking property controls whether chunking signals are present.

`Read_Data_Chunking`	Default	Meaning
`True`	No	Read data chunking is supported.
`False`	Yes	Chunking is not supported, so chunking signals are absent.

When chunking is supported, these signals are used:

Signal	Channel	Meaning
`ARCHUNKEN`	`AR`	Manager permits the Subordinate to return read data in 128-bit chunks for this transaction.
`RCHUNKV`	`R`	Indicates that `RCHUNKNUM` and `RCHUNKSTRB` are valid. It must be consistent for every response transfer of the transaction.
`RCHUNKNUM`	`R`	Identifies the chunk number being returned.
`RCHUNKSTRB`	`R`	Indicates which 128-bit chunks in the current `RDATA` transfer are valid.

Rules

Important protocol rules:

Rule	Meaning
`ARCHUNKEN` has strict transaction restrictions.	Size must be full data width or Length must be one; Size must be at least 128 bits; address must be 16-byte aligned; burst must be `INCR` or `WRAP`; opcode must be one of the legal read opcodes.
Chunked reads must use a unique in-flight ID.	There must be no other outstanding read with the same `ARID`, and `ARIDUNQ` must be asserted if present.
If `ARCHUNKEN` is LOW, `RCHUNKV` must stay LOW.	The response is returned as normal read data, not chunked data.
If `RCHUNKV` is HIGH, `RCHUNKNUM` must be between zero and `ARLEN`.	Chunk numbers must identify valid chunks for the transaction.
If `RCHUNKV` is HIGH, `RCHUNKSTRB` must not be zero.	At least one chunk must be valid in that transfer.
`RCHUNKV` must be consistent for every response transfer of a transaction.	The Manager interprets all beats of the transaction using the same chunking mode.
`RLAST` marks the final response transfer, not the highest chunk number.	The final returned transfer might not contain the numerically highest chunk.
Unaligned transactions suppress lower-address chunks.	Chunks below `ARADDR` are not transferred and must have `RCHUNKSTRB` deasserted.

The number of bytes returned must still match the transaction described by ARLEN and ARSIZE. Chunking changes the order and grouping of returned chunks; it does not change the requested byte count.

AXI Protocol