Understanding AXI4 Burst Transactions with Flow Control: A Case Study

In this article, we will delve into the inner workings of AXI4 burst transactions, specifically focusing on a scenario where an incrementing burst with AWLEN=5 and flow control via VALID and READY signals comes into play. We'll examine how AXI handles transactions under these conditions, including how the protocol handles delays and stalls.

AXI4 Burst Transactions Overview

The AXI4 (Advanced eXtensible Interface 4) protocol, widely used in high-performance systems, defines a set of rules for transferring data between master and slave devices. The protocol supports various types of transfers, including burst transfers, where a series of data is sent sequentially over multiple cycles.

In AXI, each transfer is managed by a set of signals, including:

• AWVALID: Asserted by the master to indicate that a valid address is available.
• AWREADY: Asserted by the slave to indicate that it is ready to accept the address.
• AWLEN: Specifies the burst length, indicating the number of data transfers in the burst.

An incrementing burst means that the address is incremented by the size of the data transfer, typically 4 bytes for a 32-bit wide interface, with each address being generated sequentially from the initial base address.

Scenario Setup

Consider a burst transfer where the AWLEN is set to 5. This means there will be 6 addresses in total (the initial address and 5 additional addresses). For example, if the initial address is AWADDR, the addresses would be:

• First address: AWADDR
• Second address: AWADDR + 4
• Third address: AWADDR + 8
• …
• Last address: AWADDR + 20 (for AWLEN=5)

We are also considering the scenario where both AWVALID and AWREADY signals are asserted at the first address cycle, but AWREADY is deasserted (goes low) before the next address is issued.

AXI Flow Control

One of the key features of AXI4 is its flow control mechanism. The master and slave devices use the VALID and READY signals to control the data flow. Here’s how this mechanism works:

• AWVALID: The master asserts AWVALID to indicate that the address bus has a valid address.
• AWREADY: The slave asserts AWREADY to indicate that it is ready to accept the address. When AWREADY is high, the master knows the slave is ready to receive the next address in the burst sequence.

If at any point AWREADY goes low, it means that the slave is not ready to accept the address, and the master must stall until AWREADY is asserted again.

Understanding the Flow in the Given Scenario

Let’s break down the scenario where AWREADY goes low during the burst transfer:

Initial Conditions:

• At the start of the transaction, both AWVALID and AWREADY are high, meaning the master can send the first address (AWADDR).
• The slave accepts the address, and the master is ready to send the next address in the burst.

Flow Control and Stalling:

• After the first address is sent, the master tries to send the second address. However, at this point, the slave deasserts AWREADY, meaning it’s not ready to accept the next address.
• What happens next? The master holds AWVALID high (indicating the next address is still valid) and waits for AWREADY to be asserted again by the slave.

Resuming the Burst:

• Once the slave asserts AWREADY again, the master can proceed with sending the next address in the burst. This continues until the burst is complete, and the master has sent all the addresses defined by AWLEN=5.

Conclusion of Burst:

• Once all 6 addresses (from AWADDR to AWADDR + 20 in our example) have been transmitted, the burst transfer ends.

Impact of Flow Control on Burst Transactions

The flow control mechanism in AXI ensures that the system remains synchronized even when the slave is not ready to accept an address immediately. The master is required to wait for AWREADY to be asserted before proceeding with the next address, but this does not cause a failure in the transaction.

• Stalls are Expected: It’s common for the slave to occasionally not be ready to accept data, especially in systems where there may be processing delays or resource contention.
• Synchronization: The use of AWREADY and AWVALID allows for smooth synchronization between the master and slave devices, ensuring data integrity even during delays.
• No Loss of Data: The burst transfer will continue as soon as the slave is ready to accept more addresses, and no data is lost during this process.

Conclusion

The AXI4 protocol, with its flow control signals like AWVALID and AWREADY, provides robust handling of burst transfers, even in scenarios where the slave cannot immediately accept an address. In our case, with AWLEN=5 and AWREADY going low during the burst, the protocol allows the master to stall gracefully until the slave is ready, preventing data loss or corruption.

This built-in staging mechanism is crucial for managing data flow in high-performance systems where devices operate asynchronously or under varying workloads. It ensures that the system continues to function reliably even when one side of the transaction is momentarily delayed.