Xilinx AXI-Based IP Overview


This document describes the most recent generation of Advanced Microcontroller Bus Architecture (AMBA®) interfaces, namely the AXI4 (Advanced eXtensible Interface) interconnect protocol family.

AXI Bus Functional Models Overview

A very important aspect of any System-on-a-Chip (SoC) is not only the blocks it holds but also how they are interconnected. The AMBA has been widely used as the on-chip bus in SoC designs for more than a decade [1]. Since being introduced by ARM® in 1996, the scope of this interface has gone far beyond microcontroller devices, and became the de-facto standard for a wide range of ASIC and SoC parts including processors used in today’s portable mobile devices. The AMBA interface went through several generations: the 1st one introduced the Advanced Systems Bus (ASB) and Advanced Peripheral Bus (APB), the 2nd one – the High-performance Bus (AHB), and the 3rd one – the Advanced Trace Bus (ATB) and AXI to reach even higher performance interconnect requirements driven by constantly increasing logic density on a single chip.

With multiple clusters and sophisticated peripherals in today’s SoCs, the interconnect fabric becomes a major bottleneck. The previous interconnection protocol generations just cannot keep up with the constantly growing computing power and match it with the adequate bandwidth. Given that, Xilinx has worked closely with ARM to define the AXI4, the fourth generation of the AMBA interface. The AXI specification provides a framework that defines protocols for moving data between IP using a defined signaling standard. This standard ensures that IP can exchange data with each other and that data can be moved across a system [2]. The AXI protocol defines how data is exchanged, transferred, and transformed. The AXI protocol also ensures an efficient, flexible, and predictable means for transferring data.

As part of this commitment to the AXI4, Xilinx adopted it as the next-generation IP interconnect standard for 7-Series, Spartan-6, Virtex-6, and future device families going forward.

This migration process clearly indicates that today’s Xilinx-centric SoC design methodologies and flows got extended with a new semiconductor industry's standard Plug-and-Play IP. Refer to Table 1 for the high-level list of AXI4 features available and what protocols are replaced by the AXI option.

Table 1. AXI Feature Availability and IP Replacement






High-performance memory-mapped requirements

  • Traditional memory mapped address/data interface

  • Data burst support

  • PLBv3.4/v4.6

  • OPB

  • NPI

  • XCL


Simple, low-throughput memory-mapped communication

  • Traditional memory mapped address/data interface

  • Single data cycle only

  • PLBv4.6 (singles only)

  • DCR

  • DRP


High-speed streaming data

  • Data-only burst

  • Local-Link

  • DSP

  • TRN (used in PCIe)

  • FSL

Not only do the latest Xilinx 28nm FPGAs such as Artix-7, Kintex-7, and Virtex-7 support the AXI4 interface, but Zynq™-7000 EPP supports it as well (Figure 1), enabling the development of device-independent IPs. (Zynq EPP is a new class of product which combines an industry-standard ARM® dual-core Cortex™-A9 MPCore™ processing system with Xilinx 28nm programmable logic).

Figure 1. The Role of AMBA-AXI Interconnects in Zynq EPP

The value of Zynq-7000 EPP is amplified by all of the elements supporting the Zynq-7000 family which includes hardware (HW) and software (SW) development tools, operating systems, and much more. For Hardware Designers, traditional users of Aldec tools, a number of benefits are available under the umbrella of the robust Zynq Partner Ecosystem:

  • Multiple design platforms available for evaluation, prototyping, and development

  • Rapid system configuration using intuitive design interface

  • Ability to easily extend peripheral functionality through drag & drop AXI based IPs

  • Large selection of existing proven IPs

  • System Level debugging & cross triggering between processing system and programmable logic

  • Early validation of custom peripherals through AXI Bus Functional Model


For customers relying on IP to meet their time-to-market requirements for 7-Series, Virtex-6, and Spartan-6 based designs, the AXI4 offers a single standard interface to make IP integration easier. The ISE offers a broad set of AXI4 based IP with a single open standard interface across the Embedded, DSP, and Logic domains. The AXI provides the following benefits:

  • Reduces learning curve – the AXI4 is actually a consolidated array of interfaces which means that the end users need to learn and know only one standard protocol for IP.

  • Reduces integration costs – industry standard makes it much easier to integrate the IP coming from different domains, develop in-house IP, and even work with third-party IP providers. By moving to this standard, you gain access not only to Xilinx IP catalog but also to worldwide community of ARM Partners [3].

  • Saves design time and enables you to build the most compelling products for your target markets – the actual design effort is decreased since the AXI is fully specified and optimized for performance and throughput.


When it comes to the functional verification, Bus Functional Models (BFMs) provide the ability to generate the bus stimulus and simplify the verification of hardware components that attach to a bus. The BFMs for the AXI4, including the AXI4, AXI4-Lite, and AXI4-Stream versions, were developed for Xilinx by Cadence Design Systems [4]. All of the AXI BFMs consist of three main layers: the signal interface, the channel API, and the function API [5]. The general AXI BFM architecture is shown in Figure 2. The signal interface includes the typical Verilog input/output ports and associated signals. The channel API is a set of defined Verilog tasks that operate at the basic transaction level inherent in the AXI protocol, including: Read Address Channel, Write Address Channel, Read Data Channel, Write Data Channel, and Write Response Channel.

Figure 2. AXI BFM Architecture

This split enables the tasks associated with each channel to be executed concurrently or sequentially. This allows the test writer to control and implement out of order transfers, interleaved data transfers, and other features. The function level API has complete transaction level control, for example a complete AXI read burst process is encapsulated in a single Verilog task. Test writers are encouraged to use this API layer to ensure that they comply with the AXI4 specification for channel ordering. One final but important piece of the AXI BFM architecture is the configuration mechanism. This is implemented using Verilog parameters and/or BFM internal variables and is used to set the address bus width, data bus width and other parameters – configure variables during simulation.

Figure 3. AXI BFM Usage

The intended usage of the AXI BFM is shown in Figure 3. The testbench can contain multiple instances of the AXI BFM. The DUT and BFMs are instantiated in a testbench that also contains a clock and reset generator. Then, the test writer instantiates the testbench into the test module and creates a test program using the BFM API layers. The test program would call API tasks either sequentially or concurrently using fork and join [6].


With the availability of the AXI4 protocols, ARM and Cortex processors continue maintaining a competitive advantage in the field of high-performance SoCs. The recent adoption of the AXI4 by Xilinx for all of their current and future device families and products, including the Zynq™-7000 family of Extensible Processing Platform (EPP) products [7], makes this protocol vital to learn for every SoC designer in order to be able to use the newest device families from major silicon vendors, and access a wide portfolio of AXI based IPs. Embracement by all of the major EDA vendors ensures a strong ecosystem for building AXI4-based system designs, driving ultimate productivity, and faster time to market.http://www.aldec.com/en/support/resources/documentation/articles/1586


Ask Us a Question
Ask Us a Question
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.