Wondering what is AXI and how to use it in your designs? The task of moving data from place to place is not new. As designs get larger, transferring data reliably to between HDL modules cannot be underemphasized. The AXI interface aims to unify several use-cases of data transfers. Below is a general overview of the interface and how to use it.
What is AXI?
The AXI (Advanced eXtensible Interface) specification falls under the AMBA (Advanced Micro controller Bus Architecture) specification by Arm. This interface is not a bus protocol; it is an interface description in which specifies point-to-point connections from exactly one master to one slave. The definition does not allow for multiple masters communicating to a single slave, nor having multiple modules connected to a common bus (i.e. a master communicating to multiple slaves). As we will see, there are ways around these limitations.
Specification
The AXI specification does not prescribe physical definition (i.e. does not impose voltage levels, clock speeds, etc.). Instead, it outlines an order in which reliable data transmission is achieved between a master and slave module. Several key features that the specification allows for are unaligned data transfers, burst transactions, and multiple unresolved read requests.
Unaligned Data Transfers
Unaligned data transfers primarily deal with the order in which requests are resolved, and in this case the ‘unaligned’ refers to the slave not being restricted to resolving the requests in the order the requests were received. This is achieved by the ID field of the specification.
Burst transactions
Burst transactions, typically used with a DMA (Dynamic Memory Access), to write/read large amounts of contiguous data. Contiguous data refers to data that is written to, or read from, in consecutive clock cycles. Burst transactions have several modes that determine address progression, but a common mode to write to/read from DDR, for example, is an incrementing or sequential addresses.
Read Requests
The specifications also allow for multiple read requests to remain unresolved at a given time. This may occur due to a peripheral’s inherent delay in responding, or to various internal peripheral processes. In any case, the goal of this specification is to not tie up the interface.
AXI Implementation
This interface utilizes a master/slave relationship, where the master initiates transactions and the slave resolves transactions. The master can be processors, DMA controllers, or User IP. The transaction revolves around two signals, ‘tvalid’ and ‘tready.’ The master will set ‘tvalid’ high upon initiating a request. The slave will set the ‘tready’ high when the request is resolved. On the clock cycle where both are set high, the specification states that the transaction has occurred.
Depending on the type of AXI is being implemented, several channels are utilized for the transaction. Each channel has a version of the ‘tvalid’ and ‘tready’ handshaking mechanism. The standard channels used are Read Address, Read Data, Write Address, Write Data, and Write Response.
The Different Flavors of AXI
Now, your specific use-case may not necessarily need all the features of the AXI specification. Perhaps your implementation needs to be faster ― and all those features can slow down the interface. The good news is that the specification also has variations that are less cumbersome and provide their own benefits:
- AXI-MM – also known as AXI-FULL, has the complete features of the AXI specification interface
- Mainly used for large data transfers
- Data widths up to 1024
- AXI-LITE – a smaller subset of the AXI-FULL interface
- Mainly used for command and control
- Same 5 channels, reduced number signals required.
- No bursting. Single data beat per cycle
- No unaligned data transfers
- Data widths either 32 or 64
- AXI-STREAM – a smaller subset of the AXI-LITE interface
- Single channel
- One way data transfer (master write only)
One way to help understand the structure of the specification is to notice that each of channels in of AXI-MM and AXI-LITE are essentially AXI-STREAMs with a dedicated function. So that with the Read Address, Read Data, Write Address, Write Data, and Write Response each having a separate stream, higher functional capabilities are easier to implement and prevent transactions from holding the interface hostage.
The specification has AXI-LITE as a reduced subset of the signals in AXI-FULL and defined as capable of interoperability. As such, for example, an AXI-LITE master can connect to an AXI-FULL slave without conversion logic.
Shims and Interconnects
Use Logic Shims, a form of IP, to connect differing versions of AXI. This can be useful if you find yourself attempting to connect to a peripheral that is of a different AXI version than that of the master (e.g. AXI3 and AXI4 interconnectivity).
Interconnect modules allow for the generation of multiple masters and slaves and can act like a bus of sorts. Moreover, the logic used to shuffle signals and data packets is up to the designer, but the interfaces of the module must adhere to the AXI specification. This way each interface keeps with the point-to-point, one master – one slave paradigm.
AXI related Cores in the Vivado Suite
- AXI data FIFO
- Provides flexible buffering between master and slave
- Useful for interfaces that cross clock domains
- AXI datamover
- Simple DMA
- AXI dma/cdma
- Integrated AXI datamover
- Supports scatter/gather
- Can convert AXI-STREAM to AXI-MM
- AXI protocol checkers
- For AXI-MM and AXI-STREAM
- Prints status in simulators
- AXI performance monitor
- Useful for load monitoring
- AXI Traffic Generator
- Useful during development
Additional Resources:
Xilinx AXI Reference Guide UG1037
AMBA AXI and ACE Protocol Specification (ARM IHI 0022)
AMBA 4 AXI4-Stream Protocol Specification (ARM IHI 0051)
Learn More
Interested in learning more? Watch our on-demand webinar or take a class!
