Introduction to the Advanced Extensible Interface (AXI)

In a previous article, I discussed Revision 2.0 of the Advanced Microcontroller Bus Architecture, or AMBA. AMBA is an open standard for SoC design created by Arm to allow for high performance, modular, and reusable designs that work right the first time while minimizing both power and silicon.

This article will discuss the third revision of AMBA, which introduced the Advanced Extensible Interface (AXI) protocol to the world.

Originally conceived for high-frequency systems, the AXI protocol was designed to meet the interface requirements for a wide range of components, while allowing for flexibility in how those components are interconnected. Suitable for high-frequency, low-latency designs, AXI remains backwards compatible with the AHB and APB from the previous AMBA revision.

Understanding AXI will give you deep insight into how an SoC works, while making you a versatile and well-rounded designer.

 

The AXI Architecture

Recall that the AHB (Advanced High Performance Bus) is a single channel bus that multiple masters and slaves use to exchange information. A priority arbiter determines which master currently gets to use the bus, while a central decoder performs slave selection. Operations are performed in bursts that can take multiple bus cycles to complete. Every burst transfer consists of an address and control phase followed by a data phase. 

AXI was designed with a similar philosophy but uses multiple, dedicated channels for reading and writing. AXI is burst-based like its predecessor and uses a similar address and control phase before data exchange. AXI also includes a number of new features including out-of-order transactions, unaligned data transfers, cache support signals, and a low-power interface.

 

AXI Channels

There are five independent channels between an AXI master and slave. They are the: 

• Read address channel
• Read data channel
• Write address channel 
• Write data channel
• Write response channel 

The address channels are used to send address and control information while performing a basic handshake between master and slave. The data channels are where the information to be exchanged is placed. 

A master reads data from and writes data to a slave. Read response information is placed on the read data channel, while write response information has a dedicated channel. This way the master can verify a write transaction has been completed.

Figure 1 shows an AXI master and slave connected via the five AXI channels.

 

Figure 1. AXI channels

 

Every exchange of data is called a transaction. A transaction includes the address and control information, the data sent, as well as any response information. The actual data is sent in bursts which contain multiple transfers. Figure 1 shows both a read and write burst composed of 4 beats or data transfers.

We discuss bursts in more detail later in the article.

 

AXI Signals

Much like the AHB, ASB, and APB signals from the previous AMBA revision, each of the AXI channels has a number of signals associated with it. There are two global signals referred to as ACLK and ARESETn. These are the system's global clock and reset signal, respectively. The 'n' suffix on ARESETn means this signal is active low. 

Figure 2 shows the signals corresponding to the read channels as well as the global signals.

 

Figure 2. Read address, read data, and global signals

 

Every channel has an ID tag used for out-of-order transactions. Any transaction with the same ID must remain in order, but transactions with different IDs may be completed in any order. This allows faster transactions to be completed before slower ones, even if the slower transaction was issued first. For example, if a master is writing data to multiple slaves, the transaction IDs would allow the faster slave to finish sooner.

Bus widths are implementation-specific, but these signals are shown with a 32-bit bus width. The RLAST signal is used by the slave to signal to the master that the last data item is being transferred. 

Other notable signals include the burst size, length, and type. The VALID and READY signals are used for handshaking between master and slave. These will be discussed later in the article.

The cache, lock, and protection signals are used for caching, exclusive access (atomic operations), and illegal access protection, respectively.

 

Figure 3. Write address, data, and response signals

 

Figure 3 shows the write address, data, and response signals. These signals mirror the read signals above but are used by the master to send data to a slave. WLAST signals to the slave that the last data item is being sent. The dedicated write response signals allow for a master to know that the write transaction completed successfully. 

For a more detailed description of these signals, consult AMBA revision 3.0, specifically the AMBA AXI Protocol v1.0 specification.

 

AXI Transactions

As mentioned earlier, an AXI data transfer is called a transaction. Transactions can take the form of reads or writes and include address/control information, data, and a response. The data is sent in the form of bursts, which include multiple data items called beats. To synchronize the sending and receiving of data, an AXI master and slave perform a handshake at the beginning of a transaction using the READY and VALID signals. 

 

Channel Handshake

Every AXI channel contains both a VALID and a READY signal. These are used to synchronize and control the rate of transfer. The important thing to remember here is that the source, or sender, uses the VALID signal to indicate that either data or control information is available. The destination, or receiver, signals READY when it is actually able to consume that information. Thus, a transfer can only occur when both the VALID and READY signals are asserted.

Figure 4 shows AXI handshaking at work. Notice information transfer (denoted by an arrow) only occurs when both VALID and READY are high, regardless of which was asserted first. Also note that AXI uses the rising clock edge for all transfers.

 

Figure 4. AXI handshake mechanism (adapted from AXI spec. v1.0)

 

One important note within the AXI specification is that the VALID signal of one component must never depend on the READY signal of another. READY can wait for the VALID signal, but it doesn't have to. Following these rules removes the chance of a deadlock occurring. If VALID is dependent on READY and READY is dependent on VALID, it's easy to see that neither signal may be asserted, because each one is waiting on the other.

 

AXI Bursts

Data exchanges in AXI take the form of bursts. Each burst consists of multiple beats or data transfers. Control information sent at the beginning of a transaction indicates the length, size, and type of burst being transferred. 

AXLEN[3:0], X standing in for R or W, denotes the number of beats in a burst. Being 4 bits wide, this means there can be a maximum of 16 transfers in a burst. AXLEN = b0000 means there is one beat per burst. Values of b0001, b0010, and b0011 represent two beats, three beats, and four beats, respectively. This pattern continues to sixteen. Components must complete all beats specified by AXLEN, whether it uses the data or not. 

AXSIZE[2:0] specifies how many bytes are in each beat of a burst. Each bit in AXSIZE stands for another power of two, with '000' representing 1 byte per beat and '111' representing a maximum of 128 bytes per beat. The size of these beats cannot exceed the bus width. 

AXBURST[1:0] determines the type of burst that will be performed.

There are three types of bursts in AXI. They are:

• Fixed bursts
• Incrementing bursts
• Wrapping bursts

In a fixed burst, the address doesn't change for each beat. A typical application for this is a FIFO queue/buffer.

Incrementing bursts represent the more typical type of transfer where the transfer address is incremented after each beat. You can think about this as an offset from a base address.

The final burst type is the wrapping burst. A wrapping burst is similar to an incrementing burst, except there exists a wrap boundary, wherein once the address is incremented to that point it wraps around to a lower address.

Figure 5 shows a simplified view of the three different types of AXI bursts.

 

Figure 5. AXI burst types

 

AXI Interconnects

AXI interconnects allow multiple masters and/or multiple slaves to interface with each other. The AXI specification defines the interface between a master and slave, a master and interconnect, and a slave and interconnect.

In reality, interconnects contain slave interfaces that connect to AXI masters and master interfaces that connect to AXI slaves. What goes on in an interconnect—i.e., how different masters communicate to different slaves—depends on the implementation. Interconnects can allow a shared address bus, shared data bus, both shared, or neither shared.

In the next article, we will take a look at AXI interconnects, how they work, and how to use them in design.

 

Conclusion

This article was a basic introduction to the Advanced Extensible Interface (AXI) protocol. We looked at legacy AXI as specified in the third revision of AMBA. As I mentioned above, you can refer to AMBA AXI Protocol v1.0 (roughly a hundred pages) for a deeper look into the first version of AXI. AXI has seen some significant changes in AMBA revision 4 with new versions of AXI like AXI4, AXI4-Lite, and AXI4-Stream.

Future AMBA articles will discuss AXI4 and the ACE protocol (AXI Coherency Extensions) used for system-level cache coherency between components. AXI has become a widely used protocol in modern SoC design. In learning AXI, simpler bus protocols like Avalon and Wishbone will come much easier.

To reiterate what I asserted in the introduction, you will have advantages in SoC design if you understand AXI. I hope this article has helped you on your way.