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.
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.
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.
The specifications of the protocol are quite simple, and are summarized below:
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.
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.
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.