AXI Protocol

The Advanced eXtensible Interface (AXI) protocol is an on-chip interconnect protocol used in modern Systems-on-Chip (SoC) designs to connect multiple masters and slaves. It defines a transaction model based on identifier-tagged bursts that supports both ordered and out-of-order completion, along with optional extensions for cache coherency, stashing, and snoopable accesses.

Transaction model and ordering

AXI uses AXI transaction identifiers (IDs) to decouple the order in which a master issues transactions from the order in which a slave completes them.

• All transactions issued with the same AXI ID value must remain ordered.
• There is no restriction on the ordering of transactions with different ID values.
• A single physical port can therefore act as multiple logical ports, each handling its transactions in order; this enables parallel processing of transactions and improves system performance.
• Slaves are required to reflect the appropriate BID (or RID for read responses) on receiving an AXI ID from a master, so the response can be matched back to the originating request.

There is no mandatory requirement for slaves or masters to use AXI IDs; masters and slaves may instead process one transaction at a time, in which case transactions are processed in the order they are issued.

Multi-master and multi-slave arbitration

Because an SoC integrates many IP blocks, AXI designs commonly include:

• Multiple masters accessing a single slave simultaneously, where the system bus must arbitrate and sequence transactions properly and each transaction must be followed by a valid read or write response.
• A single master issuing transactions to multiple slaves, with randomized IDs so the master can throw unordered transactions to different slaves concurrently, and the testbench must check that the appropriate BID/RID is returned by each slave.

Verification and stimulus generation

AXI is commonly verified through constrained-random stimulus:

• The protocol is one of the protocols typically supported in SoC testbenches. From a generic stimulus base class, protocol-specific derived classes such as random_axi are used to randomize and convert generic commands into AXI commands.
• AXI IDs are randomized at the master so that out-of-order transactions to different slaves can be exercised concurrently.
• Scenario tests include unaligned-address and boundary-address accesses, back-to-back transactions with randomized inter-master delays, and cache-coherency tests that combine core execution in non-sharing mode with IO masters issuing snoopable reads and randomized L2 stashing.
• Coverage closure targets AXI-specific checks such as correct BID/RID reflection and valid response ordering.

Extensions and protocol variants

Some open-source and proprietary RISC-V cores use non-standard AXI protocol extensions alongside custom interrupt and debug interfaces. Compliance with the standard AXI protocol, debug, and interrupt interfaces is therefore an explicit design goal when integrating these cores into an SoC.

Security: protocol-violation attacks

In modern SoCs, the AXI protocol exhibits security vulnerabilities that can be exploited to achieve partial or complete denial-of-service (DoS) through protocol-violation attacks. These attacks involve header-field manipulation and systematic malicious operations that evade protocol-compliance checks. Recent countermeasures have lacked a dedicated real-time protocol semantic analysis.

Hardware monitoring of AXI

An Intelligent Monitoring System (IMS) has been proposed as a hardware module that monitors AXI bus activity in real time to detect protocol violations:

• It uses a neural-network classifier trained on recorded AXI transactions captured during DoS-style header-field manipulation attacks.
• A quantization-optimized neural network achieves 98.7% detection accuracy with ≤3% latency overhead and >2.5 million inferences/s throughput.
• When integrated into a RISC-V SoC as a memory-mapped IP core and demonstrated on an AMD Zynq UltraScale+ MPSoC ZCU104 board, it occupies approximately 9.04% LUTs, 0.23% DSP slices, and 0.70% flip-flops, with negligible impact on achievable design frequency.

Typical bugs uncovered with AXI-based CSR

Constrained-random verification (CRV) on AXI traffic has been observed to expose several classes of bugs:

• Swapped control signals between modules, surfaced only when all masters and slaves are simultaneously active.
• Latency inconsistencies versus architecture expectations, discovered only when the system is fully choked with high traffic. These can cause:
  • Overrun/underrun errors in FIFOs.
  • In Time-Division Multiplexing (TDM) subsystems, late data-packet arrival in jitter buffers leading to dropped packets and distortion.
  • Corresponding overrun/underrun errors in jitter buffers that degrade voice quality, requiring buffer-depth or clock-frequency adjustments.

Verification tips relevant to AXI

Practical tips drawn from AXI-based SoC bug hunting include:

• Enable all monitors and checkers for automatic data comparing and protocol checking.
• Use back-door access for register reads/writes in the device under test (DUT) when thousands of register writes would otherwise be resource- and time-consuming via the front-door physical bus.
• Use weight-based control for the number and size of transactions from different masters, weight-based control for transaction type (read, write, snoopable, etc.), randomized inter-master delays, and standard monitors with coverage sampling and exclude lists.

Related concepts

• See also: AXI Transaction ID Randomization (the technique of randomizing AXI IDs at the master to drive unordered transactions to multiple slaves).
• See also: random_axi stimulus class (a protocol-specific stimulus class derived from a generic stimulus base class to randomize and convert generic commands into AXI commands).
• See also: Bug hunting SoC designs to achieve full functional coverage closure (the paper that describes the random_axi derivation, AXI-based bug-hunting scenarios, and CSR methodology).