Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
  • Groups
    • Arm Research
    • DesignStart
    • Education Hub
    • Graphics and Gaming
    • High Performance Computing
    • Innovation
    • Multimedia
    • Open Source Software and Platforms
    • Physical
    • Processors
    • Security
    • System
    • Software Tools
    • TrustZone for Armv8-M
    • 中文社区
  • Blog
    • Announcements
    • Artificial Intelligence
    • Automotive
    • Healthcare
    • HPC
    • Infrastructure
    • Innovation
    • Internet of Things
    • Machine Learning
    • Mobile
    • Smart Homes
    • Wearables
  • Forums
    • All developer forums
    • IP Product forums
    • Tool & Software forums
  • Support
    • Open a support case
    • Documentation
    • Downloads
    • Training
    • Arm Approved program
    • Arm Design Reviews
  • Community Help
  • More
  • Cancel
System
  • Developer Community
  • IP Products
  • System
  • Jump...
  • Cancel
System
SoC Design blog Introduction to AXI Protocol: Understanding the AXI interface
  • Blogs
  • Forums
  • Videos & Files
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
  • New
More blogs in System
  • Embedded blog

  • SoC Design blog

Tags
  • AMBA
  • aldec
  • AXI
  • SoC Design
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Introduction to AXI Protocol: Understanding the AXI interface

Christina Toole
Christina Toole
October 24, 2016

When part of a team, your group can become more capable than a single individual, but only if your team can work together and communicate effectively. Having members of a group talk over each other leads to nothing but a cacophony, and nothing gets done. For this reason protocols need to be established, such as letting others speak without interruption, or facing those you are addressing. The same is necessary with electronics, especially with system on chip (SoC) designs.

Introducing the AXI Protocol

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.

My first introduction with the interface was in a tutorial I was following that was to be implemented on Aldec’s own development board based off the Zynq XC7Z030, the TySOM™ board. The project utilized several of the board’s peripheral connections including HDMI, touchscreen, LEDs, and switches. Despite the various types of inputs and outputs, the IP cores all shared a common interface: AXI. Knowing the differences between these devices, I was interested in why each IP Core was able to share this common interface. Reading more into the technology I found out just why AXI has become the most widespread AMBA interface.

How AXI became the most widespread AMBA interface

The protocol simply sets up the rules for how different modules on a chip communicate with each other, requiring a handshake-like procedure before all transmissions. Having a protocol such as this allows a true “system” rather than a “collection” of modules to be established as the protocol connects and provides an effective medium for transfer of data between the existing components on the chip.

Channel Connections

Protocol specifications

The specifications of the protocol are quite simple, and are summarized below:

  • Before transmission of any control signal/address/data, both master and slave must extend their “hand” for a handshake via ready and valid signals.
  • Separate phases exist for transmission of control signal/address and data.
  • Separate channels exist for transmission of control signal/address and data.
  • Burst type communication allows for continuous transfer of data.

To go more in depth, the interface works by establishing communication between master and slave devices. Between these two devices (or more if using an AXI Interconnect Core IP) exists five separate channels: Read Address, Write Address, Read Data, Write Data, and Write Response. Each channel has its own unique signals as well as similar signals existing among all five. The valid and ready signals exist for each channel as they allow for the handshake process to occur for each channel. For transmitting any signal (address/data/response/etc) the relevant channel source provides an active valid signal and the same channel’s destination must provide an active ready signal. After both signals are active, transmission may occur on that channel. As stated above, the transmission of control signals/address and data are done in separate phases, and therefore an address must always be transferred between devices before the handshake process can occur for the corresponding data transfer. In the case of writing information, the response channel is used at the completion of the data transfer.

Ready and valid signals

Summary

There it is. The protocol is that easy! Of course there are additional options that the protocol provides that up the complexity somewhat, such as burst transfer, QoS, Protections, and others. These options are simply extra signals existing on the different channels that allow for additional functionality, for general use however, the above description gets the point across on how this interface generally works.

Once I understood the basic idea of the AXI protocol it was much easier to understand the tutorial I was going through. The project I was building in Vivado was no longer just a bunch of blocks with random connections, but instead were the various peripherals of the TySOM board all connected with a common bus interface. By learning about this one interface I was able to understand all the various connections of the design due to the interface’s general use. This isn’t just true for the TySOM project as, being an industry standard, knowing the AXI protocol allows for a better understanding of all Arm based chips utilizing this AMBA specification.

Author

This blog is authored by Brandon Wade, Aldec FAE Intern. Brandon is currently working on his B.S. in computer engineering from the University of Nevada, Las Vegas and is set to graduate in 2017. His interests include processor architectures, and the logic of these hardware designs. As a field application engineer intern, Brandon has worked extensively with Aldec's own simulation software such as Active-HDL and Riviera-PRO.

Anonymous
SoC Design blog
  • A painless upgrade to 22nm – the right cost with the available IP

    Claudia Pike
    Claudia Pike
    In this blog, read about upgrading to 22nm in your ASIC design feature.
    • August 27, 2020
  • Simplifying workload modeling with AMBA ATP Engine

    Francisco Socal
    Francisco Socal
    Following the release of the AMBA Adaptive Traffic Profiles (ATP) Specification, we are pleased to announce the AMBA ATP Engine, to further facilitate ATP’s adoption into a variety of platforms.
    • May 20, 2020
  • Docker enables Arm Cycle Model Studio on Ubuntu

    Jason Andrews
    Jason Andrews
    Arm Cycle Model Studio (CMS) is a great tool to create SystemC simulation models from Verilog RTL source code. This articles shows how to use Docker to run CMS and create models on an Ubuntu machine.
    • October 23, 2019