AXI transport describes how each channel moves one transfer from a transmitter to a receiver. The protocol defines a global clock and reset per interface, then lets the interface choose one of two transport styles: Valid-Ready transport or credited transport.

Clock

Every AXI interface has one clock, ACLK. Inputs are sampled on the rising edge of ACLK, and output signal changes occur only after the rising edge. The specification forbids combinatorial paths between input and output signals on an interface. That rule is not cosmetic; it is what lets designers insert register stages and close timing without creating unstable feedback paths.

Reset

AXI uses an active-low reset, ARESETn. Reset can assert asynchronously, but deassertion must be synchronous to a rising edge of ACLK. Signals that must be deasserted during reset, such as VALID, must remain deasserted until at least the rising edge after ARESETn is sampled HIGH.

AXI transport options

The AXI_Transport property selects the transport style used by all AXI channels on an interface. Connected Manager and Subordinate interfaces must use the same transport style. The Ready value selects Valid-Ready transport; the Credited value selects credited transport and is available for AXI5 interfaces.

AXI_Transport	Default	Description
Credited		AXI channels use `CRDT` flow-control signals.
Ready	Y	AXI channels use `READY` flow-control signals

Valid-Ready transport

Valid-Ready transport is the default AXI transport. As listed in Signal Description, each channel has a VALID side and a READY side. This section focuses on the timing rule: a transfer occurs on a rising ACLK edge when both are HIGH.

The transmitter must not wait for READY before asserting VALID. Once VALID is asserted, it must remain asserted until a transfer occurs. The receiver is allowed to wait for VALID before asserting READY, and it is also allowed to assert READY before VALID.

VALID before READY

In this timing example, the transmitter presents information and asserts VALID before the receiver asserts READY. The payload must remain stable until the rising edge where VALID and READY are both HIGH.

READY before VALID

In this example, the receiver is already ready before the transmitter asserts VALID. When the transmitter presents valid information, the transfer can complete with minimum latency.

Dependencies between channel handshake signals

There are dependencies between channels for write, read, and snoop transactions. In the dependency diagrams, a single-headed arrow means the signal at the arrowhead can be asserted before or after the signal at the start of the arrow. A double-headed arrow means the signal at the arrowhead must be asserted only after the signal at the start of the arrow.

Write transaction dependencies

The write path has three channels: AW, W, and B. AXI allows the write request channel and write data channel to be accepted independently. Write data can arrive before, with, or after the write request, depending on register stages and implementation.

The key dependency is the write response. A Subordinate must not assert BVALID until it has accepted the write request and the final write data transfer. The final write data transfer is identified by WLAST when WLAST is present.

The key idea is that 'AW' and 'W' can make progress independently, but the 'B' response depends on the accepted write request and the final accepted write data transfer.

Dependency point	Rule
Manager drives write request/data	The Manager must not wait for the Subordinate to assert `AWREADY` or `WREADY` before asserting `AWVALID` or `WVALID`. This applies to every write data transfer in a transaction.
Subordinate drives `AWREADY` after seeing valid	The Subordinate can wait for `AWVALID` or `WVALID`, or both, before asserting `AWREADY`.
Subordinate drives `AWREADY` early	The Subordinate can assert `AWREADY` before `AWVALID` or `WVALID`, or both, are asserted.
Subordinate drives `WREADY` after seeing valid	The Subordinate can wait for `AWVALID` or `WVALID`, or both, before asserting `WREADY`.
Subordinate drives `WREADY` early	The Subordinate can assert `WREADY` before `AWVALID` or `WVALID`, or both, are asserted.
Write response waits for request and data handshakes	The Subordinate must wait for `AWVALID`, `AWREADY`, `WVALID`, and `WREADY` to be asserted before asserting `BVALID`.
Write response waits for final data beat	The Subordinate must wait for the last write data transfer before asserting `BVALID`. The last write data transfer has `WLAST` asserted.
Subordinate drives write response	The Subordinate must not wait for the Manager to assert `BREADY` before asserting `BVALID`.
Manager accepts response after valid	The Manager can wait for `BVALID` before asserting `BREADY`.
Manager accepts response early	The Manager can assert `BREADY` before `BVALID` is asserted.

Read transaction dependencies

The read path has two channels: 'AR' and 'R'. The Subordinate must not return read data before the read request has been accepted. The Manager must be able to accept read data for a request it issued, without relying on unrelated transactions.

The request handshake on 'AR' must complete before the Subordinate can return valid read data on 'R'.

Dependency point	Rule
Manager drives read request	The Manager must not wait for the Subordinate to assert `ARREADY` before asserting `ARVALID`.
Subordinate drives `ARREADY` after seeing request	The Subordinate can wait for `ARVALID` to be asserted before it asserts `ARREADY`.
Subordinate drives `ARREADY` early	The Subordinate can assert `ARREADY` before `ARVALID` is asserted.
Read data waits for accepted request	The Subordinate must wait for both `ARVALID` and `ARREADY` to be asserted before it asserts `RVALID` to indicate that valid data is available.
Subordinate drives read data	The Subordinate must not wait for the Manager to assert `RREADY` before asserting `RVALID`.
Manager accepts read data after valid	The Manager can wait for `RVALID` to be asserted before it asserts `RREADY`.
Manager accepts read data early	The Manager can assert `RREADY` before `RVALID` is asserted.

Read data can be delayed, and different IDs can permit interleaving or out-of-order completion, but every returned RID must match the ARID of the request being completed.

Credited transport

Credited transport is an AXI5 option. Instead of READY, the receiver gives credits using CRDT signals. The transmitter can assert VALID only when it owns the appropriate credit. A credit cannot be used in the same cycle it is given, and a credit cannot be given in the same cycle it is used for a transfer.

Credited transport signals

Credited channels can include:

Signal	Source	Meaning
`VALID`	Transmitter	One transfer is being sent.
`PENDING`	Transmitter	A transfer might occur in the following cycle. Useful for transfer-level clock gating.
`RP`	Transmitter	Resource Plane number when more than one Resource Plane exists.
`SHAREDCRD`	Transmitter	Transfer uses a shared credit.
`CRDT`	Receiver	Gives one dedicated credit for a Resource Plane.
`CRDTSH`	Receiver	Gives one shared credit.

Credited flow control

In credited transport, a credit is permission to send one future transfer. The receiver owns the buffering, so it decides when to give credits. The transmitter keeps a small credit count for each channel and Resource Plane, then sends VALID only when the appropriate count is nonzero.

Event	Effect at transmitter	Important rule
Reset active	Dedicated and shared credit counts are zero.	`CRDT` and `CRDTSH` are LOW during reset.
`CRDT[n]` asserted	Adds one dedicated credit for Resource Plane `n`.	A credit cannot be used for a transfer in the same cycle it is given.
`CRDTSH` asserted	Adds one shared credit.	Shared credits are only present when the channel supports them.
`VALID` asserted using a dedicated credit	Consumes one dedicated credit for the selected Resource Plane.	`VALID` is illegal if the selected Resource Plane has zero dedicated credits and no shared credit is used.
`VALID` asserted using a shared credit	Consumes one shared credit and asserts `SHAREDCRD`.	The selected Resource Plane is still shown on `RP` when `RP` is present.

The receiver must be able to give at least one dedicated credit per Resource Plane. It can give up to 15 credits per Resource Plane, and up to 15 shared credits when shared credits are supported. There must not be combinatorial paths between credit signals and other channel signals, so a design should treat credits as registered state.

A simple credited-transfer waveform is easiest to understand by tracking the transmitter credit count. The labeled points map as follows:

Point	Signal event	Credit-count view
`a`	`ARESETn` is released.	The transmitter still owns zero credits after reset, so `VALID` remains LOW.
`b`	The receiver asserts `CRDT`.	One credit is given to the transmitter. This credit is for a later cycle, not for a same-cycle transfer.
`c`	The transmitter asserts `VALID`.	The transmitter uses a credit it already owns. In the shown example, `VALID` remains HIGH for two cycles, so two transfers consume two previously given credits.
`d`	The receiver asserts `CRDT` again.	A credit is returned after receiver space is available again. The transmitter records it for a later transfer.
`e`	The transmitter asserts `VALID` again.	The transmitter uses the returned credit from `d` on a later cycle.

The main lesson is that CRDT is a promise for a future transfer, not a same-cycle READY signal. A transmitter must already own a credit before it asserts VALID.

Resource Planes

Resource Planes let traffic sharing one physical channel make progress independently. A Resource Plane is a flow-control partition inside a credited channel. It is not a new AXI channel and it does not create a separate address, data, or response path. Instead, it divides the channel credits into independent credit pools.

For example, an AW channel can carry requests from different traffic classes. If all requests shared one credit pool, a blocked class could consume or hold the only available buffering and stop another class from moving. With Resource Planes, each plane has its own dedicated credits. A transfer on Resource Plane 0 uses Resource Plane 0 credits, while a transfer on Resource Plane 1 uses Resource Plane 1 credits. This lets one plane make progress even when another plane has no available credits.

The RP signal identifies which Resource Plane a transfer belongs to. The receiver gives credits per Resource Plane using CRDT bits, and the transmitter must spend a credit from the same Resource Plane as the transfer. This is why Resource Planes are mainly a flow-control and deadlock-avoidance mechanism, not an ordering mechanism.

Name	Values	Default	Description
`Num_RP_AWW`	1-8	1	Number of Resource Planes on the `AW` and `W` channels.
`Num_RP_AR`	1-8	1	Number of Resource Planes on the `AR` channel.

AR, AW, and W can have multiple Resource Planes. B and R have one Resource Plane. If a channel has more than one Resource Plane, the RP signal identifies the Resource Plane used by the transfer. If a channel has one Resource Plane, the RP signal is absent.

Resource Plane rule	Meaning
Different Resource Planes must not block one another between transmitter and receiver.	A stalled plane must not consume the only path for a different plane that has credit.
Credits are counted per Resource Plane.	A transmitter can issue on Resource Plane `n` only when it has credit for Resource Plane `n`, unless it uses a shared credit.
`AW` and `W` for the same write transaction use the same Resource Plane number.	The write request and write data stay associated through the credited channel.
Different Resource Planes do not create ordering guarantees.	A Manager must not use the same ID for an outstanding transaction on the same channel with a different Resource Plane.
Write data for different transactions can be interleaved across Resource Planes.	Verification must track write data order per Resource Plane, not just globally.

This example shows one credited channel configured with three Resource Planes and shared credits. The waveform is useful because it separates four related ideas: dedicated credits for each Resource Plane, shared credits that can be used by any Resource Plane, the RP value of each transfer, and the credit counters maintained by the transmitter.

Cycle	What happens	What it teaches
0	The transmitter has no credits.	No transfer can be sent until the receiver gives credit.
1	The receiver gives one dedicated credit for each Resource Plane and one shared credit.	Each `CRDT[n]` bit increases the credit count for Resource Plane `n`; `CRDTSH` increases the shared credit count.
2	The transmitter sends a transfer on Resource Plane 1 using a dedicated credit.	`VALID` is HIGH, `RP` identifies Resource Plane 1, and `SHAREDCRD` is LOW because a dedicated credit is used.
3	The receiver gives a dedicated credit back for Resource Plane 1.	The receiver can return credit when it has space for another transfer on that Resource Plane.
5	The transmitter sends a transfer on Resource Plane 2 using a dedicated credit.	Dedicated Resource Plane 2 credit is consumed.
6	The transmitter sends another transfer on Resource Plane 2 using a shared credit.	`SHAREDCRD` is asserted because no dedicated Resource Plane 2 credit is available for that transfer.
7	The receiver gives back a shared credit and a dedicated Resource Plane 2 credit.	Shared and dedicated credits are counted separately.
8	The transmitter sends a transfer on Resource Plane 0 using a dedicated credit.	A different Resource Plane can make progress independently.
9	The receiver gives back a dedicated Resource Plane 0 credit and another shared credit.	Returned credits become available for later transfers.

The most important point is that RP tells which Resource Plane the transfer belongs to, while SHAREDCRD tells which kind of credit is being spent. A transfer can use a shared credit and still belong to a specific Resource Plane.

Shared credits

Shared credits are optional for channels with multiple Resource Planes. They are a flexible credit pool that can be used by any Resource Plane. This improves buffer utilization when traffic is uneven, because an idle Resource Plane does not have to reserve all of its buffering while another Resource Plane is busy.

Shared credit properties

Name	Values	Default	Description
`Shared_Credits_AW`	True, False	False	If True, shared credits are supported on the `AW` channel using `AWCRDTSH` and `AWSHAREDCRD`.
`Shared_Credits_W`	True, False	False	If True, shared credits are supported on the `W` channel using `WCRDTSH` and `WSHAREDCRD`.
`Shared_Credits_AR`	True, False	False	If True, shared credits are supported on the `AR` channel using `ARCRDTSH` and `ARSHAREDCRD`.

Shared credit rule	Meaning
Shared credits require credited transport and multiple Resource Planes.	They are not used with Valid-Ready transport or with a single Resource Plane.
`CRDTSH` gives one shared credit.	The receiver can give a shared credit without giving a dedicated `CRDT` credit in the same cycle.
`SHAREDCRD` is asserted with `VALID` when the transfer consumes a shared credit.	The receiver can distinguish dedicated-credit transfers from shared-credit transfers.
A shared credit can be used for any Resource Plane.	The transfer still belongs to the Resource Plane indicated by `RP`.
Resource Plane independence still applies.	Shared credits must not let one Resource Plane block another in a way that violates the Resource Plane guarantee.

If both a dedicated credit and a shared credit are available, a transmitter should normally use the dedicated credit first. The shared credit is more flexible and can be saved for a later transfer on a Resource Plane that has no dedicated credit.

Credited transport matters most in high-frequency designs where a simple READY feedback path is too timing-sensitive. It also changes ordering details: write data can be interleaved across transactions when those transactions use different Resource Planes.

Transfer-level clock gating

For credited transport, PENDING is a one-cycle look-ahead signal. It tells the receiver that a transfer might occur in the following cycle, so receiver-side logic can ungate its clock before VALID and payload signals arrive.

`PENDING` rule	Meaning
There is one `PENDING` signal per channel.	It is channel-level, not per Resource Plane.
`PENDING` must be HIGH in the cycle before `VALID` is HIGH.	The receiver gets one cycle of warning before a transfer.
If `PENDING` is LOW, `VALID` must be LOW in the next cycle.	A transfer cannot appear without the look-ahead indication.
If `PENDING` is HIGH, `VALID` is permitted but not required in the next cycle.	`PENDING` means “might transfer,” not “must transfer.”
`PENDING` is independent of credits.	A transmitter can assert `PENDING` before it receives a credit, keep it HIGH permanently, or assert it and later deassert it without sending a transfer.

Pipelining and register stages

AXI channels are independent and unidirectional. Register stages can be inserted on any channel, with an added cycle of latency. This lets a design trade latency for timing closure: a fast path to memory might have few stages, while a long path to a peripheral can add register slices.

Pipelining rule	Meaning
Any number of register stages can be inserted on `VALID`, `READY`, and `CRDT` paths.	AXI is designed to tolerate registered timing paths.
Different channels can have different numbers of register stages.	`AW`, `W`, `B`, `AR`, and `R` do not need matching latency.
`VALID` and payload are pipelined together.	Address, data, control, `RP`, and `SHAREDCRD` must stay aligned with their `VALID`.
`PENDING` keeps its timing relationship to `VALID`.	In credited transport, `PENDING` remains HIGH in the cycle before `VALID` is HIGH.

This independence is powerful, but it forces real interconnects to be careful. The protocol does not require channels to keep the same-cycle timing relationship. Write data can arrive before the write request at an interface point if the AW path has more register stages than the W path. If an interconnect uses address decoding to determine where write data should go, it must realign AW and W before forwarding data to the selected Subordinate.

Key points

The relationships that must still be preserved are:

Relationship	Required behavior
Write response after write data	A write response follows the last write data transfer of the write transaction.
Read data after read request	Read data and read response follow the accepted read request.
Manager write-data responsibility	After issuing a write request, the Manager must be able to provide all write data for that transaction without depending on other transactions from that Manager.
Manager response responsibility	After issuing a write request and all write data, the Manager must be able to accept all responses for that transaction without depending on other transactions from that Manager.
Manager read-data responsibility	After issuing a read request, the Manager must be able to accept all read data for that transaction without depending on other transactions from that Manager.
Data-less write requests	A Subordinate must not block data-less write requests because other transactions have leading write data.

AXI Protocol