Advanced eXtensible Interface

Last updated

The Advanced eXtensible Interface (AXI) is an on-chip communication bus protocol and is part of the Advanced Microcontroller Bus Architecture specification (AMBA). [1] [2] AXI had been introduced in 2003 with the AMBA3 specification. In 2010, a new revision of AMBA, AMBA4, defined the AXI4, AXI4-Lite and AXI4-Stream protocols. AXI is royalty-free and its specification is freely available from ARM.

Contents

AMBA AXI specifies many optional signals, which can be included depending on the specific requirements of the design, [3] making AXI a versatile bus for numerous applications.

While the communication over an AXI bus is between a single initiator and a single target, the specification includes detailed descriptions and signals to include N:M interconnects, able to extend the bus to topologies with multiple initiators and targets. [4]

AMBA AXI4, AXI4-Lite and AXI4-Stream have been adopted by Xilinx and many of its partners as a main communication bus in their products. [5] [6]

Thread IDs

Thread IDs allow a single initiator port to support multiple threads, where each thread has in-order access to the AXI address space, however each thread ID initiated from a single initiator port may complete out of order with respect to each other. For instance in the case where one thread ID is blocked by a slow peripheral, another thread ID may continue independently of the order of the first thread ID. Another example, one thread on a cpu may be assigned a thread ID for a particular initiator port memory access such as read addr1, write addr1, read addr1, and this sequence will complete in order because each transaction has the same initiator port thread ID. Another thread running on the cpu may have another initiator port thread ID assigned to it, and its memory access will be in order as well but may be intermixed with the first thread IDs transactions.

Thread IDs on an initiator port are not globally defined, thus an AXI switch with multiple initiator ports will internally prefix the initiator port index to the thread ID, and provide this concatenated thread ID to the target device, then on return of the transaction to its initiator port of origin, this thread ID prefix will be used to locate the initiator port and the prefix will be truncated. This is why the target port thread ID is wider in bits than the initiator port thread ID.

Axi-lite bus is an AXI bus that only supports a single ID thread per initiator. This bus is typically used for an end point that only needs to communicate with a single initiator device at a time, example, a simple peripheral such as a UART. In contrast, a CPU is capable of initiating transactions to multiple peripherals and address spaces at a time, and will support more than one thread ID on its AXI initiator ports and AXI target ports. This is why a CPU will typically support a full spec AXI bus. A typical example of a front side AXI switch would include a full specification AXI initiator connected to a CPU initiator, and several AXI-lite targets connected to the AXI switch from different peripheral devices.

(Additionally, the AXI-lite bus is restricted to only support transaction lengths of a single data word per transaction.)

Handshake

Basic handshake mechanism of the AMBA AXI protocol. In this example, the destination entity waits for a high VALID to assert its own READY. AMBA AXI Handshake.svg
Basic handshake mechanism of the AMBA AXI protocol. In this example, the destination entity waits for a high VALID to assert its own READY.

AXI defines a basic handshake mechanism, composed by an xVALID and xREADY signal. [7] The xVALID signal is driven by the source to inform the destination entity that the payload on the channel is valid and can be read from that clock cycle onwards. Similarly, the xREADY signal is driven by the receiving entity to notify that it is prepared to receive data.

When both the xVALID and xREADY signals are high in the same clock cycle, the data payload is considered transferred and the source can either provide a new data payload, by keeping high xVALID, or terminate the transmission, by de-asserting xVALID. An individual data transfer, so a clock cycle when both xVALID and xREADY are high, is called "beat".

Two main rules are defined for the control of these signals:

Thanks to this handshake mechanism, both the source and the destination can control the flow of data, throttling the speed if needed.

Channels

In the AXI specification, five channels are described: [8]

Other than some basic ordering rules, [9] each channel is independent from each other and has its own couple of xVALID/xREADY handshake signals. [10]

AXI read channels.svg
AXI Read Address and Read Data channels.
AXI write channels.svg
AXI Write Address, Write Data and Write Response channels.

AXI

Signals

Signals of the Read and Write Address channels
Signal descriptionWrite Address channelRead Address channel
Address ID, to identify multiple streams over a single channel AWIDARID
Address of the first bit of the burstAWADDRARADDR
Number of bits inside the burstAWLEN [nb 1] ARLEN [nb 1]
Size of each bitAWSIZEARSIZE
Type of the burstAWBURSTARBURST
Lock type, to provide atomic operations AWLOCK [nb 1] ARLOCK [nb 1]
Memory type, how the transaction has to progress through the systemAWCACHEARCACHE
Protection type: privilege, security level and data/instruction accessAWPROTARPROT
Quality of service of the transactionAWQOS [nb 2] ARQOS [nb 2]
Region identifier, to access multiple logical interfaces from a single physical oneAWREGION [nb 2] ARREGION [nb 2]
User-defined dataAWUSER [nb 2] ARUSER [nb 2]
xVALID handshake signalAWVALIDARVALID
xREADY handshake signalAWREADYARREADY
Signals of the Read and Write Data channels
Signal descriptionWrite Data channelRead Data channel
Data ID, to identify multiple streams over a single channel WID [nb 3] RID
Read/Write dataWDATARDATA
Read response, to specify the status of the current RDATA signalRRESP
Byte strobe, to indicate which bytes of the WDATA signal are validWSTRB
Last bit identifierWLASTRLAST
User-defined dataWUSER [nb 2] RUSER [nb 2]
xVALID handshake signalWVALIDRVALID
xREADY handshake signalWREADYRREADY
Signals of the Write Response channel
Signal descriptionWrite Response channel
Write response ID, to identify multiple streams over a single channel BID
Write response, to specify the status of the burstBRESP
User-defined dataBUSER [nb 2]
xVALID handshake signalBVALID
xREADY handshake signalBREADY

[11]

  1. 1 2 3 4 Different behavior between AXI3 and AXI4
  2. 1 2 3 4 5 6 7 8 9 Available only with AXI4
  3. Available only with AXI3

Bursts

Example of FIXED, INCR and WRAP bursts AXI Bursts.svg
Example of FIXED, INCR and WRAP bursts

AXI is a burst-based protocol, [12] meaning that there may be multiple data transfers (or beats) for a single request. This makes it useful in the cases where it is necessary to transfer large amount of data from or to a specific pattern of addresses. In AXI, bursts can be of three types, selected by the signals ARBURST (for reads) or AWBURST (for writes): [13]

In FIXED bursts, each beat within the transfer has the same address. This is useful for repeated access at the same memory location, such as when reading or writing a FIFO.

In INCR bursts, on the other hand, each beat has an address equal to the previous one plus the transfer size. This burst type is commonly used to read or write sequential memory areas.

WRAP bursts are similar to the INCR ones, as each transfer has an address equal to the previous one plus the transfer size. However, with WRAP bursts, if the address of the current beat reaches the "Higher Address boundary", it is reset to the "Wrap boundary":

with

Transactions

Reads

Example of an AXI read transaction. The initiator requests 4 beats (ARLEN + 1 ) of 4 Bytes each starting from address 0x0 with INCR type. The target returns 0x10 for address 0x0, 0x11 for address 0x4, 0x12 for address 0x8 and 0x13 for address 0xc, all with the OKAY status. Only the most relevant signals are shown here. AXI read transaction.svg
Example of an AXI read transaction. The initiator requests 4 beats (ARLEN + 1 ) of 4 Bytes each starting from address 0x0 with INCR type. The target returns 0x10 for address 0x0, 0x11 for address 0x4, 0x12 for address 0x8 and 0x13 for address 0xc, all with the OKAY status. Only the most relevant signals are shown here.

To start a read transaction, the initiator has to provide on the Read address channel:

  • the start address on ARADDR
  • the burst type, either FIXED, INCR or WRAP, on ARBURST (if present)
  • the burst length on ARLEN (if present).

Additionally, the other auxiliary signals, if present, are used to define more specific transfers.

After the usual ARVALID/ARREADY handshake, the target has to provide on the Read data channel:

  • the data corresponding to the specified address(es) on RDATA
  • the status of each beat on RRESP

plus any other optional signals. Each beat of the target's response is done with a RVALID/RREADY handshake and, on the last transfer, the target has to assert RLAST to inform that no more beats will follow without a new read request.

Writes

Example of an AXI write transaction. The initiator drives 4 beats (AWLEN + 1 ) of 4 Bytes each starting from address 0x0 with INCR type, writing 0x10 for address 0x0, 0x11 for address 0x4, 0x12 for address 0x8 and 0x13 for address 0xc. The target returns 'OKAY' as write response for the whole transaction. Only the most relevant signals are shown here. AXI write transaction.svg
Example of an AXI write transaction. The initiator drives 4 beats (AWLEN + 1 ) of 4 Bytes each starting from address 0x0 with INCR type, writing 0x10 for address 0x0, 0x11 for address 0x4, 0x12 for address 0x8 and 0x13 for address 0xc. The target returns 'OKAY' as write response for the whole transaction. Only the most relevant signals are shown here.

To start a write operation, the initiator has to provide both the address information and the data ones.

The address information are provided over the Write address channel, in a similar manner as a read operation:

  • the start address has to be provided on AWADDR
  • the burst type, either FIXED, INCR or WRAP, on AWBURST (if present)
  • the burst length on AWLEN (if present)

and, if present, all the optional signals.

An initiator has also to provide the data related to the specified address(es) on the Write data channel:

  • the data on WDATA
  • the "strobe" bits on WSTRB (if present), which conditionally mark the individual WDATA bytes as "valid" or "invalid"

Like in the read path, on the last data word, WLAST has to be asserted by the initiator.

After the completion of both the transactions, the target has to send back to the initiator the status of the write over the Write response channel, by returning the result over the BRESP signal.

AXI4-Lite

AXI4-Lite is a subset of the AXI4 protocol, providing a register-like structure with reduced features and complexity. [15] Notable differences are:

AXI4-Lite removes part of the AXI4 signals but follows the AXI4 specification for the remaining ones. Being a subset of AXI4, AXI4-Lite transactions are fully compatible with AXI4 devices, permitting the interoperability between AXI4-Lite initiators and AXI4 targets without additional conversion logic. [16]

Signals

Write address channelWrite data channelWrite response channelRead address channelRead data channel
AWVALIDWVALIDBVALIDARVALIDRVALID
AWREADYWREADYBREADYARREADYRREADY
AWADDRWDATABRESPARADDRRDATA
AWPROTWSTRBARPROTRRESP

[17]

AXI-Stream

See also

Related Research Articles

<span class="mw-page-title-main">Peripheral Component Interconnect</span> Local computer bus for attaching hardware devices

Peripheral Component Interconnect (PCI) is a local computer bus for attaching hardware devices in a computer and is part of the PCI Local Bus standard. The PCI bus supports the functions found on a processor bus but in a standardized format that is independent of any given processor's native bus. Devices connected to the PCI bus appear to a bus master to be connected directly to its own bus and are assigned addresses in the processor's address space. It is a parallel bus, synchronous to a single bus clock. Attached devices can take either the form of an integrated circuit fitted onto the motherboard or an expansion card that fits into a slot. The PCI Local Bus was first implemented in IBM PC compatibles, where it displaced the combination of several slow Industry Standard Architecture (ISA) slots and one fast VESA Local Bus (VLB) slot as the bus configuration. It has subsequently been adopted for other computer types. Typical PCI cards used in PCs include: network cards, sound cards, modems, extra ports such as Universal Serial Bus (USB) or serial, TV tuner cards and hard disk drive host adapters. PCI video cards replaced ISA and VLB cards until rising bandwidth needs outgrew the abilities of PCI. The preferred interface for video cards then became Accelerated Graphics Port (AGP), a superset of PCI, before giving way to PCI Express.

<span class="mw-page-title-main">USB</span> Standard for computer data connections

Universal Serial Bus (USB) is an industry standard that allows data exchange and delivery of power between many various types of electronics. It specifies its architecture, in particular its physical interface, and communication protocols for data transfer and power delivery to and from hosts, such as personal computers, to and from peripheral devices, e.g. displays, keyboards, and mass storage devices, and to and from intermediate hubs, which multiply the number of a host's ports.

Direct memory access (DMA) is a feature of computer systems that allows certain hardware subsystems to access main system memory independently of the central processing unit (CPU).

<span class="mw-page-title-main">I²C</span> Serial communication bus

I2C (Inter-Integrated Circuit; pronounced as “eye-squared-see” or “eye-two-see”), alternatively known as I2C or IIC, is a synchronous, multi-master/multi-slave (controller/target), single-ended, serial communication bus invented in 1982 by Philips Semiconductors. It is widely used for attaching lower-speed peripheral ICs to processors and microcontrollers in short-distance, intra-board communication.

HyperTransport (HT), formerly known as Lightning Data Transport, is a technology for interconnection of computer processors. It is a bidirectional serial/parallel high-bandwidth, low-latency point-to-point link that was introduced on April 2, 2001. The HyperTransport Consortium is in charge of promoting and developing HyperTransport technology.

<span class="mw-page-title-main">PCI Express</span> Computer expansion bus standard

PCI Express, officially abbreviated as PCIe or PCI-e, is a high-speed serial computer expansion bus standard, designed to replace the older PCI, PCI-X and AGP bus standards. It is the common motherboard interface for personal computers' graphics cards, sound cards, hard disk drive host adapters, SSDs, Wi-Fi and Ethernet hardware connections. PCIe has numerous improvements over the older standards, including higher maximum system bus throughput, lower I/O pin count and smaller physical footprint, better performance scaling for bus devices, a more detailed error detection and reporting mechanism, and native hot-swap functionality. More recent revisions of the PCIe standard provide hardware support for I/O virtualization.

<span class="mw-page-title-main">IEEE-488</span> General Purpose Interface Bus (GPIB) specification

IEEE 488, also known as HP-IB and generically as GPIB, is a short-range digital communications 8-bit parallel multi-master interface bus specification developed by Hewlett-Packard. It subsequently became the subject of several standards.

<span class="mw-page-title-main">Cache coherence</span> Computer architecture term concerning shared resource data

In computer architecture, cache coherence is the uniformity of shared resource data that ends up stored in multiple local caches. When clients in a system maintain caches of a common memory resource, problems may arise with incoherent data, which is particularly the case with CPUs in a multiprocessing system.

A controller area network is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles to save on copper, but it can also be used in many other contexts. For each device, the data in a frame is transmitted serially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off. Frames are received by all devices, including by the transmitting device.

JTAG is an industry standard for verifying designs and testing printed circuit boards after manufacture.

<span class="mw-page-title-main">Serial Attached SCSI</span> Point-to-point serial protocol for enterprise storage

In computing, Serial Attached SCSI (SAS) is a point-to-point serial protocol that moves data to and from computer-storage devices such as hard disk drives and tape drives. SAS replaces the older Parallel SCSI bus technology that first appeared in the mid-1980s. SAS, like its predecessor, uses the standard SCSI command set. SAS offers optional compatibility with Serial ATA (SATA), versions 2 and later. This allows the connection of SATA drives to most SAS backplanes or controllers. The reverse, connecting SAS drives to SATA backplanes, is not possible.

The MicroBlaze is a soft microprocessor core designed for Xilinx field-programmable gate arrays (FPGA). As a soft-core processor, MicroBlaze is implemented entirely in the general-purpose memory and logic fabric of Xilinx FPGAs.

The Arm Advanced Microcontroller Bus Architecture (AMBA) is an open-standard, on-chip interconnect specification for the connection and management of functional blocks in system-on-a-chip (SoC) designs. It facilitates development of multi-processor designs with large numbers of controllers and components with a bus architecture. Since its inception, the scope of AMBA has, despite its name, gone far beyond microcontroller devices. Today, AMBA is widely used on a range of ASIC and SoC parts including applications processors used in modern portable mobile devices like smartphones. AMBA is a registered trademark of Arm Ltd.

<span class="mw-page-title-main">Low Pin Count</span> Low-bandwidth computer motherboard bus

The Low Pin Count (LPC) bus is a computer bus used on IBM-compatible personal computers to connect low-bandwidth devices to the CPU, such as the BIOS ROM, "legacy" I/O devices, and Trusted Platform Module (TPM). "Legacy" I/O devices usually include serial and parallel ports, PS/2 keyboard, PS/2 mouse, and floppy disk controller.

<span class="mw-page-title-main">USB On-The-Go</span> Specification for USB devices

USB On-The-Go is a specification first used in late 2001 that allows USB devices, such as tablets or smartphones, to also act as a host, allowing other USB devices, such as USB flash drives, digital cameras, mouse or keyboards, to be attached to them. Use of USB OTG allows devices to switch back and forth between the roles of host and device. For example, a smartphone may read from removable media as the host device, but present itself as a USB Mass Storage Device when connected to a host computer.

CoreConnect is a microprocessor bus-architecture from IBM for system-on-a-chip (SoC) designs. It was designed to ease the integration and reuse of processor, system, and peripheral cores within standard and custom SoC designs. As a standard SoC design point, it serves as the foundation of IBM or non-IBM devices. Elements of this architecture include the processor local bus (PLB), the on-chip peripheral bus (OPB), a bus bridge, and a device control register (DCR) bus. High-performance peripherals connect to the high-bandwidth, low-latency PLB. Slower peripheral cores connect to the OPB, which reduces traffic on the PLB. CoreConnect has bridging capabilities to the competing AMBA bus architecture, allowing reuse of existing SoC-components.

The Open Core Protocol (OCP) is a protocol for on-chip subsystem communications. It is an openly licensed, core-centric protocol and defines a bus-independent, configurable interface. OCP International Partnership (OCP-IP) produces OCP specifications. OCP data transfer models range from simple request-grant handshaking through pipelined request-response to complex out-of-order operations.

<span class="mw-page-title-main">IEEE 1394</span> Serial bus interface standard, also known as Firewire

IEEE 1394 is an interface standard for a serial bus for high-speed communications and isochronous real-time data transfer. It was developed in the late 1980s and early 1990s by Apple in cooperation with a number of companies, primarily Sony and Panasonic. It is most commonly known by the name FireWire (Apple), though other brand names exist such as i.LINK (Sony), and Lynx.

MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile and mobile-influenced space. The MIPI Alliance MIPI Debug Working Group has released a portfolio of specifications; their objective is to provide standard debug protocols and standard interfaces from a system on a chip (SoC) to the debug tool. The whitepaper Architecture Overview for Debug summarizes all the efforts. In recent years, the group focused on specifying protocols that improve the visibility of the internal operations of deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices, and specifying the use of I3C as debugging bus.

The Gen-Z Consortium is a trade group of technology vendors involved in designing CPUs, random access memory, servers, storage, and accelerators. The goal was to design an open and royalty-free "memory-semantic" bus protocol, which is not limited by the memory controller of a CPU, to be used in either a switched fabric or a point-to-point device link on a standard connector.

References

  1. "AMBA | Documentation". Arm Holdings.
  2. Toole, Christina (24 October 2016). "Introduction to AXI Protocol: Understanding the AXI interface". arm.com. Arm Limited. Retrieved 11 September 2023. The protocol used by many SoC designers today is AXI, or Advanced eXtensible Interface, and is part of the Arm Advanced Microcontroller Bus Architecture (AMBA) specification. It is especially prevalent in Xilinx's Zynq devices, providing the interface between the processing system and programmable logic sections of the chip.
  3. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 109–118. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  4. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 23–24. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  5. "AMBA AXI4 Interface Protocol". www.xilinx.com. Xilinx Inc.
  6. "AXI4 IP". www.xilinx.com. Xilinx Inc.
  7. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 37–38. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  8. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 22–23. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  9. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 40. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  10. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 38. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  11. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 28–34. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  12. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 22. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  13. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 45–47. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  14. 1 2 Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 44. Retrieved 5 July 2019.
  15. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. pp. 121–128. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  16. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 124. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.
  17. Arm Holdings. "AMBA AXI and ACE Protocol Specification" (PDF). developer.arm.com. p. 122. Archived from the original (PDF) on 5 July 2019. Retrieved 5 July 2019.