Channel transfers and transactions

This section explains the handshake principle for AXI channels, and shows how the handshake is the underpinning mechanism for all read and write transactions.

Channel handshake

The AXI4 protocol defines five different channels, as described in AXI channels. All of these channels share the same handshake mechanism that is based on the VALID and READY signals, as shown in the following diagram:

The VALID signal goes from the source to the destination, and READY goes from the destination to the source.

Whether the source or destination is a master or slave depends on which channel is being used. For example, the master is a source for the Read Address channel, but a destination for the Read Data channel.

The source uses the VALID signal to indicate when valid information is available. The VALID signal must remain asserted, meaning set to high, until the destination accepts the information. Signals that remain asserted in this way are called sticky signals.

The destination indicates when it can accept information using the READY signal. The READY signal goes from the channel destination to the channel source.

This mechanism is not an asynchronous handshake, and requires the rising edge of the clock for the handshake to complete.

Differences between transfers and transactions

When designing interconnect fabric, you must know the capabilities of the masters and slaves that are being connected. Knowing this information lets you include sufficient buffering, tracking, and decode logic to support the various data transfer ordering possibilities that allow performance improvements in faster devices.

Using standard terminology makes understanding the interactions between connected components easier. AXI makes a distinction between transfers and transactions:

  • A transfer is a single exchange of information, with one VALID and READY handshake. The following diagram shows a transfer:

  • A transaction is an entire burst of transfers, containing an address transfer, one or more data transfers, and, for write sequences, a response transfer. The following diagram shows a transaction:

Channel transfer examples

This section examines some examples of possible handshakes between source and destination. It shows several possible combinations of VALID and READY sequences that conform to the AXI protocol specifications.

In the first example, shown in the following diagram, we have a clock signal, followed by an information bus, and then the VALID and READY signals:

This example has the following sequence of events:

  1. In clock cycle 2, the VALID signal is asserted, indicating that the data on the information channel is valid.
  2. In clock cycle 3, the following clock cycle, the READY signal is asserted.
  3. The handshake completes on the rising edge of clock cycle 4, because both READY and VALID signals are asserted.

The following diagram shows another example:

This example has the following sequence of events:

  1. In clock cycle 1, the READY signal is asserted.
  2. The VALID signal is not asserted until clock cycle 3.
  3. The handshake completes on the rising edge of clock cycle 4, when both VALID and READY are asserted.

The final example shows both VALID and READY signals being asserted during the clock cycle 3, as seen in the following diagram:

Again, the handshake completes on the rising edge of clock cycle 4, when both VALID and READY are asserted.

In all three examples, information is passed down the channel when READY and VALID are asserted on the rising edge of the clock signal.

Read and write handshakes must adhere to the following rules:

  • A source cannot wait for READY to be asserted before asserting VALID.
  • A destination can wait for VALID to be asserted before asserting READY.

These rules mean that READY can be asserted before or after VALID, or even at the same time.

Write transaction: single data item

This section describes the process of a write transaction for a single data item, and the different channels that are used to complete the transaction.

This write transaction involves the following channels:

  • Write Address (AW)
  • Write (W)
  • Write Response (B)

First, there is a handshake on the Write Address (AW) channel, as shown in the following diagram:

This handshake is where the master communicates the address of the write to the slave. The handshake has the following sequence of events:

  1. The master puts the address on AWADDR and asserts AWVALID in clock cycle 2.
  2. The slave asserts AWREADY in clock cycle 3 to indicate its ability to receive the address value.
  3. The handshake completes on the rising edge of clock cycle 4.

After this first handshake, the master transfers the data to the slave on the Write (W) channel, as shown in the following diagram:

The data transfer has the following sequence of events:

  1. The slave is waiting for data with WREADY set to high in clock cycle n.
  2. The master puts the data on the WDATA bus and asserts WVALID in clock cycle n+2.
  3. The handshake completes on the rising edge of clock cycle n+3

Finally, the slave uses the Write Response (B) channel, to confirm that the write transaction has completed once all WDATA has been received. This response is shown in the following diagram:

The write response has the following sequence of events:

  1. The master asserts BREADY.
  2. The slave drives BRESP to indicate success or failure of the write transaction, and asserts BVALID.

The handshake completes on the rising edge of clock cycle n+3.

Write transaction: multiple data items

AXI is a burst-based protocol, which means that it is possible to transfer multiple data in a single transaction. We can transfer a single address on the AW channel to transfer multiple data, with associated burst width and length information.

The following diagram shows an example of a multiple data transfer:

In this case, the AW channel indicates a sequence of three transfers, and on the W channel, we see three data transfers.

The master drives the WLAST high to indicate the final WDATA. This means that the slave can either count the data transfers or just monitor WLAST.

Once all WDATA transfers are received, the slave gives a single BRESP value on the B channel. One single BRESP covers the entire burst. If the slave decides that any of the transfers contain an error, it must wait until the entire burst has completed before it informs the master that an error occurred.

Read transaction: single data item

This section looks in detail at the process of a read transaction for a single data item, and the different channels used to complete the transaction.

This write transaction involves the following channels:

  • Read Address (AR)
  • Read (R)

First, there is a handshake on the Read Address (AR) channel, as shown in the following diagram:

The handshake has the following sequence of events:

  1. In clock cycle 2, the master communicates the address of the read to the slave on ARADDR and asserts ARVALID.
  2. In clock cycle 3, the slave asserts ARREADY to indicate that it is ready to receive the address value.

The handshake completes on the rising edge of clock cycle 4.

Next, on the Read (R) channel, the slave transfers the data to the master. The following diagram shows the data transfer process:

The data transfer handshake has the following sequence of events:

  1. In clock cycle n, the master indicates that it is waiting to receive the data by asserting RREADY.
  2. The slave retrieves the data and places it on RDATA in clock cycle n+2. In this case, because this is a single data transaction, the slave also sets the RLAST signal to high.

    At the same time, the slave uses RRESP to indicate the success or failure of the read transaction to the master, and asserts RVALID.

  3. Because RREADY is already asserted by the master, the handshake completes on the rising edge of clock cycle n+3.

Read transaction: multiple data items

The AXI protocol also allows a read burst of multiple data transfer in the same transaction. This is similar to the write burst that is described in Write transaction: multiple data items.

The following diagram shows an example of a burst read transfer:

In this example, we transfer a single address on the AR channel to transfer multiple data items, with associated burst width and length information.

Here, the AR channel indicates a sequence of three transfers, therefore on the R channel, we see three data transfers from the slave to the master.

On the R channel, the slave transfers the data to the master. In this example, the master is waiting for data as shown by RREADY set to high. The slave drives valid RDATA and asserts RVALID for each transfer.

One difference between a read transaction and a write transaction is that for a read transaction there is an RRESP response for every transfer in the transaction. This is because, in the write transaction, the slave has to send the response as a separate transfer on the B channel. In the read transaction, the slave uses the same channel to send the data back to the master and to indicate the status of the read operation.

If an error is indicated for any of the transfers in the transaction, the full indicated length of the transaction must still be completed. There is no such thing as early burst termination.

Active transactions

Active transactions are also known as outstanding transactions.

An active read transaction is a transaction for which the read address has been transferred, but the last read data has not yet been transferred at the current point in time.

With reads, the data must come after the address, so there is a simple reference point for when the transaction starts. This is shown in the following diagram:

For write transactions, the data can come after the address, but leading write data is also allowed. The start of a write transaction can therefore be either of the following:

  • The transfer of the write address
  • The transfer of leading write information

Therefore, an active write transaction is a transaction for which the write address or leading write data has been transferred, but the write response has not yet been transferred.

The following diagram shows an active write transaction where the write address has been transferred, but the write response has not yet been transferred:

The following diagram shows an active write transaction where the leading write data has been transferred, but the write response has not yet been transferred:

Previous Next