Transfer behavior and transaction ordering

This section of the guide analyzes some example sequences of read and write transactions, to help you understand the relationships between the different AXI channels. This section also explains some of the rules that govern transactions and how transfer IDs can support out-of-order transactions.

We will also look at:

  • Unaligned transfers, and how they help optimize bandwidth utilization
  • The differences between big-endian and little-endian encoding, with some simple examples
  • The main parameters that are related to the AXI interfaces. These parameters are useful when implementing an interconnect

Examples of simple transactions

Examples of simple transactions help to explain the relationships between the different AXI channels.

The following diagram shows a time representation of several valid transactions on the five channels of an AXI3 or AXI4 interface:

The different transactions in this example are as follows:

  1. Transaction A, which is a write transaction that contains four transfers.

    The requester first puts the address A on the AW channel, then soon puts the sequence of four data transfers on the W channel, ending with AL where L stands for last.

    Once all four data transfers complete, the completer responds on the channel.

  2. While transaction A was occurring, the requester also used the read channels to perform a read transaction, C, which contains two transfers.

    Because this is a read transaction, there is no response from the completer on a different channel when the transaction completes. Instead, the response from the completer is included in the R channel at the same time as the data.

  3. Once transaction C completes, the requester uses the Read Address channel AR to send a new read address, D, to the completer.

    In this case, the response from the completer is not immediate. This is indicated by the empty time slot between D and D0. Delays like this can happen. The completer is not obliged to answer immediately. For example, the completer could be busy performing another operation, or it could take time to retrieve the data.

    Eventually, the completer responds with four sequential transfers, D0 through DL, on the R channel.

  4. Finally, while the read transaction D is ongoing, the requester uses the Write Address channel, AW, to send a new address, B, to the completer for a write operation.

    The requester puts the data B0 on the W channel at the same time as it puts the corresponding address B on the AW channel. There is a delay in this example between data transfers B0 and BL, and another delay before the response B. The transaction completes only when the completer sends the response to the requester.

All of these examples are valid transactions.

The following diagram shows the same sequence of read and write transactions in a different, but still valid, timeline:

In this example, the requester starts transaction B before it has finished transaction A.

The requester uses the Write Address channel, AW, to start a new transaction by transferring a new address B to the completer before it has finished transferring the data for transaction A on the W channel.

The data for transaction B is transferred to the completer when all the data for transaction A have completed. The requester does not wait for a response on the B channel for transaction A before it starts to transfer the data for transaction B.

At the same time, the requester uses the Read Address channel to transfer in sequence the read addresses C and D for the completer. The completer responds in sequence to the two read requests.

This example shows a different valid combination of read and write transactions happening on the different channels. This shows the flexibility of the AXI protocol and the possibility to optimize the interconnect performance.

Transfer IDs

The AXI protocol defines an ID signals bus for each channel. Marking each transaction with an ID gives the possibility to complete transactions out of order. This means that transactions to faster memory regions can complete without waiting for earlier transactions to slower memory regions. The use of transfer IDs enables the implementation of a high-performance interconnect, maximizing data throughput and system efficiency. This feature can also improve system performance because it reduces the effect of transaction latency.

The ID signal buses are as follows:

  • AWID
  • WID
  • BID
  • ARID
  • RID

The AXI protocol supports out-of-order transactions by enabling each interface to act as multiple ordered interfaces. According to the AXI protocol specifications, all transactions with a given ID must be ordered. However, there is no restriction on the ordering of transactions with different IDs.

When working with transfer IDs, follow these rules:

  • All transfers must have an ID.
  • All transfers in a transaction must have the same ID.
  • Requesters can support multiple IDs for multiple threads.
  • Completers generally need a configurable ID width.

You should also remember these two important AXI parameters for ID signals:

  • The write ID width, which is the number of bits used for the AWID, WID and BID buses
  • The read ID width, which is the number of bits used for the ARID and RID buses

Write transaction ordering rules

There are three AXI ordering rules for write transactions.

The rules are as follows:

  • Write data on the W channel must follow the same order as the address transfers on the AW channel.

    The following diagram illustrates this rule:

    In this example, the requester issues address A then B, so data must start with A0 before B0.

    Note: The interleaving of write data with different IDs on the W channel was permitted in AXI3, but is deprecated in AXI4 and later.

  • Transactions with different IDs can complete in any order.

    The following diagram illustrates this rule:

    In this example, transaction B completes before transaction A, even though transaction A started first.

  • A requester can have multiple outstanding transactions with the same ID, but they must be performed in order and complete in order.

    The following diagram illustrates this rule:

    In this example, transaction B has a different ID from the other transactions, so it can complete at any point. However, transactions A and C have the same ID, so they must complete in the same order as they were issued: A first, then C.

Read transaction ordering rules

There are three ordering rules for read transactions.

The rules are as follows:

  • Read data for different IDs on the R channel has no ordering restrictions. This means that the completer can send it in any order.

    The following diagram shows an example where transaction B is serviced before A, even though the address for transaction A is received first:

  • The read data for the different IDs on the R channel can be interleaved, with the RID value differentiating which transaction the data relates to.

    The following diagram shows an example where R data for transactions A and B are interleaved:

  • For transactions with the same ID, read data on the R channel must be returned in the order that they were requested.

    The following diagram shows an example where transactions A and C have the same RID value of 0:

    Because transaction A was requested before transaction C, the completer must return all four R data values for A before the data values for C.

Read and write channel ordering

Read and write channels have no ordering rules in relation to each other. This means that they can complete in any order. So, if a requester requires ordering for a specific sequence of reads and writes, the requester must ensure that the transaction order is respected by explicitly waiting for transactions to complete before issuing new ones.

The following diagram shows an example where the requester requires a specific ordering for a write-read-write transaction sequence from an address:

The sequence of operations is as follows:

  1. The requester starts the first write transaction.
  2. The requester ensures that the completer has completed the write transaction by waiting for the signal on the Write Response channel.
  3. The requester starts the read transaction.
  4. The requester waits for the final response on the Read Data channel.
  5. The requester starts the second transaction.

Unaligned transfer start address

The AXI protocol supports transactions with an unaligned start address that only affects the first transfer in a transaction. After the first transfer in a transaction, all other transfers are aligned.

Note: The AXI protocol also supports unaligned transfers using the strobe signals. See Write data strobes for more information.

An unaligned transfer is where the AxADDR values do not have to be aligned to the width of the transaction. For example, a 32-bit data packet that starts at a byte address of 0x1002 is not aligned to the natural 32-bit address boundary because 0x1002 is not exactly divisible by 0x20.

The following example shows a 5-beat 32-bit transfer starting at an unaligned address of 0x01:

If the transaction were aligned to a start address of 0x00, the result would be a five-beat burst with a width of four bytes giving a maximum data transfer of 20 bytes. However, we have an unaligned start address of 0x1. This reduces the total data volume of the transfer, but it does not mean a final unaligned transfer to complete the burst and make up the volume. In this example, the first transfer starts at address 0x01 and contains three bytes. All the following transfers in the burst are aligned with the bus width and are composed of four bytes each. The following example shows a five-beat 16-bit-sized transaction starting at address 0x03:

If the transaction were aligned to a start address of 0x00, the result would be a five-beat burst with a width of two bytes giving a maximum data transfer of 10 bytes. In this example, the first transfer starts at an unaligned address of 0x03 and contains one byte. All the following transfers in the burst are aligned with the bus width and are composed of two bytes each.

The AXI protocol does not require the completer to take special action based on any alignment information from the requester.

Endianness support

The AXI protocol supports mixed-endian structures in the same memory space by using Big Endian-8 (BE-8) mode. Compared to little-endian mode, the same byte lanes are used in BE-8 mode, but the order of the bytes is reversed.

Note: Mixed-endian structures using BE-32 are more complicated than those using BE-8, because byte lanes are not the same as little-endian mode.

The following example shows both little-endian and big-endian representations of the same four-byte word:

For a four-byte word in little-endian mode, the most significant byte uses the most significant byte lane, which is byte lane 3. In BE-8 mode, the most significant byte uses the least significant byte lane, which is byte lane 0.

The following example shows both little-endian and big-endian representations of the same two-byte word:

For a halfword of two bytes in little-endian mode, the most significant byte uses byte lane 1, and the least significant byte uses byte lane 0. Again, in big-endian BE-8 mode, the lanes that are used by the two bytes are switched. The most significant byte uses byte lane 0, and least significant byte uses byte lane 1.

Finally, for a single byte, there is no difference between little-endian and big-endian mode, as shown in the following example:

In both cases, the byte uses byte lane 0.

In a configurable endianness component like an Arm core, which supports BE-8, the reordering of the bytes should be performed internally, so that nothing has to be done at the interconnect level. On the other hand, a custom device that is connected to the AXI interconnect, which is BE-8 by nature, would already have the correct order of bytes. Having BE-8 in the AXI protocol eases the support for dynamic endianness switching.

Read and write interface attributes

This section of the guide highlights some of the most important attributes for configuring AXI write and read channels.

The write interface attributes include the following:

Write issuing capability
Represents the maximum number of active write transactions the requester interface can generate
Write interleave capability (AXI3 only)
The number of active write transactions for which the requester interface is capable of transmitting data.
Write acceptance capability (AXI3 only)
Represents the maximum number of active write transactions the completer interface can accept
Write interleave depth attribute
Represents the number of active write transactions that the completer interface can receive data from

The read interface attributes include the following:

Read issuing capability attribute
Represents the maximum number of active read transactions that a requester interface can generate
Read acceptance capability
The maximum number of active read transactions that a completer interface can accept
Read data reordering depth
The number of active read transactions for which a completer interface can transmit data, counted from the earliest transaction
Previous Next