Understanding AMBA Bus Architechture and Protocols

The Advanced Micro controller Bus Architecture (AMBA) bus protocols is a set of interconnect specifications from ARM that standardizes on chip communication mechanisms between various functional blocks (or IP) for building high performance SOC designs. These designs typically have one or more micro controllers or microprocessors along with several other components — internal memory or external memory bridge, DSP, DMA, accelerators and various other peripherals like USB, UART, PCIE, I2C etc — all integrated on a single chip. The primary motivation of AMBA protocols is to have a standard and efficient way to interconnecting these blocks with re-use across multiple designs.



The first step in learning AMBA protocols is to understand where exactly these different protocols are used , how these evolved and how all of them fit into a SOC design.Following diagram (reference from the AMBA 2.0 spec) illustrates a traditional AMBA based SOC design that uses the AHB (Advanced High performance) or ASB (Advanced System Bus) protocols for high bandwidth interconnect and an APB (Advanced Peripheral Bus) protocol for low bandwidth peripheral interconnects.



With increasing number of functional blocks (IP) integrating into SOC designs, the shared bus protocols (AHB/ASB) started hitting limitations sooner and in 2003 , the new revision of AMBA 3 introduced a point to point connectivity protocol — AXI (Advanced Extensible Interface). Further in 2010, an enhanced version was introduced — AXI 4. Following diagram illustrates this evolution of protocols along with the SOC design trends in industry.

Following diagram illustrates how an AXI interconnect can be used to build an SOC with various functional blocks talking through a master-slave protocol. The interconnect could be a custom crossbar or a switch design or even an off the shelve NOC (Network on Chip) IP that supports multiple AXI masters and slaves. The AXI interconnect helps in scaling up connectivity for number of agents compared to previous AHB/ASB bus. An AXI to APB bridge on one of the slave port is normally used to bridge communications to a set of peripherals shared on an APB bus.

Further evolution happened in the era of mobile and smartphones with SOCs having dual/quad/octa core processors with shared caches integrated and the need for hardware managed coherency across the memory subsystem. This lead to the introduction of ACE (AXI Coherency Protocol Extension) in AMBA revision 4.

Lastly, in the current era of heterogeneous computing for HPC and data center markets, the integration trend continues with increasing number of processor cores along with several heterogeneous computing elements like GPU, DSP, FPGAs, memory controllers and IO sub systems. In 2013, AMBA 5 introduced the CHI (Coherent Hub Interconnect) protocol as a re-design of the AXI/ACE protocol. The signal based AXI/ACE protocol was replaced with the new packet based CHI layered protocol that can scale very well for near term future.

Now that hopefully you understand how the protocols evolved and how each of them fit in to an SOC design— here are few basics and references to resources that you can use to learn more in depth about each of the protocol.

ARM has open sourced all of the protocols and all the specifications can be downloaded from the ARM website free by signing up.

  1. APB : The Advanced Peripheral Bus (APB) is used for connecting low bandwidth peripherals. It is a simple non-pipelined protocol that can be used to communicate(read or write) from a bridge/master to a number of slaves through the shared bus. The reads and writes shares the same set of signals and no burst data transfers are supported. The latest spec (APB 2.0) is available on ARM website here and is a relatively easy protocol to learn.
  2. AHB: The Advanced High-performance Bus (AHB) is used for connecting components that need higher bandwidth on a shared bus. These could be a internal memory or an external memory interface, DMA , DSP etc but the shared bus would limit the number of agents. Similar to APB, this is a shared bus protocol for multiple masters and slaves, but higher bandwidth is possible through burst data transfers. The latest spec can be found on ARM website here and is relatively easy to learn
  3. AHB-lite protocol is a simplified version of AHB. The simplification comes with support for only a single master design and that removes need for any arbitration, retry, split transactions etc.
  4. AXI: The Advanced Extensible interface (AXI) is useful for high bandwidth and low latency interconnects. This is a point to point interconnect and overcomes the limitations of a shared bus protocol in terms of number of agents that can be connected. The protocol also was an enhancement from AHB in terms of supporting multiple outstanding data transfers (pipe-lined), burst data transfers, separate read and write paths and supporting different bus widths.
  5. AXI-lite protocol is a simplified version of AXI and the simplification comes in terms of no support for burst data transfers.
  6. AXI-stream protocol is another flavor of the AXI protocol that supports only streaming of data from a master to a slave. There is no separate read/write channels in the stream protocol unlike a full AXI or AXI-lite as the intend is to only stream in one direction. Multiple streams of data can be transferred (even with interleaving) across a master and slave. This becomes useful in designs like video streaming applications.
  7. The full AXI and AXI-lite specification can be downloaded on ARM website here. The AXI-stream protocol has a different spec and is available here for download.
  8. ACE — AXI Coherence extension protocol is an extension to AXI 4 protocol and evolved in the era of multiple CPU cores with coherent caches getting integrated on a single chip. The ACE protocol extends the AXI read and write data channels by introducing separate snoop address, snoop data and snoop response channels. These extra channels provides mechanisms to implement a snoop based coherency protocol. If you are new to coherency, understanding that will be a pre-requisite before learning ACE protocol. The spec is available for download from ARM here as part of AXI4 spec
  9. ACE-Lite — The ACE also has a simplified version of protocol for those agents that does not have a cache of its own but still are part of the shareable coherency domain. Typical agents like DMA or network interface agents fall implement this “one-way” coherency using a ACE-lite protocol.
  10. CHI —( Coherent Hub Interface) — The ACE protocol was developed as an extension to AXI to support coherent interconnects. The ACE protocol used a signal level communication between master/slave and hence the interconnects needed large number of wires with added channels for snoops and responses. This worked well for small coherent clusters with dual/quad core mobile SOC designs. With increasing number of coherent clusters on SOC along with other heterogeneous compute elements and memory controllers — the AMBA 5 revision introduced CHI protocol as a complete re-design of the ACE protocol. The CHI protocol uses a layered packet based communication protocol with protocol, link layer and physical layer implementation and also supports QoS based flow control and retry mechanisms.


Hope this gives an overview and helps getting started to learn more in depth into these protocols. The best way to learn further is to read the specifications to understand details of each protocol. The APB and AHB are relatively easy and can be learned easily. AXI and ACE/CHI are relatively complex and will need detailed reading along with understanding of basics of cache coherency and general communication protocols.

If you are not actively working on any of these on any projects, but do have time, you can also develop a IP/VIP for a master or slave for any of these protocols, simulate and understand the details in depth.


This is a guest post by Ramdas Mozhikunnath. For more related topics and questions on Verification/VLSI, do refer to Ramsas Quora profile – https://www.quora.com/profile/Ramdas-Mozhikunnath