Skip to content
STIMSMITH

AXI Protocol

Concept

The Advanced eXtensible Interface (AXI) protocol is a widely used on-chip bus protocol in modern Systems-on-Chip (SoC) designs that supports ordered and out-of-order transactions, multiple masters and slaves, cache-coherent operations, and protocol-specific extensions. It is leveraged for verification stimulus randomization, transaction-ID based ordering, and hardware-level security monitoring, and is subject to protocol-violation attacks that can be detected by neural-network-based monitors.

First seen 7/1/2026
Last seen 7/1/2026
Evidence 2 chunks
Wiki v1

WIKI

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

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

3 connections
The paper uses AXI protocol as one of the SoC protocols for stimulus generation.
AXI Transaction ID Randomization ← uses 100% 1e
AXI transaction ID randomization applies to the AXI protocol's ID mechanism.
random_axi stimulus class ← implements 100% 1e
The random_axi stimulus class implements AXI protocol commands.

CITATIONS

9 sources
9 citations — click to expand
[1] AXI uses transaction identifiers (IDs) where all transactions with the same AXI ID value must remain ordered, while transactions with different ID values have no ordering restriction, and slaves must reflect the appropriate BID or RID on receiving an AXI ID from a master. Bug hunting SoC designs to achieve full functional coverage closure
[2] Masters and slaves are not required to use AXI transaction IDs; they may process one transaction at a time in the order issued. Bug hunting SoC designs to achieve full functional coverage closure
[3] Multiple-master to single-slave AXI scenarios require proper bus arbitration, sequencing, and valid read/write responses; single-master to multiple-slave scenarios use randomized AXI IDs to issue unordered transactions concurrently while checking BID/RID reflection. Bug hunting SoC designs to achieve full functional coverage closure
[4] AXI is one of the protocols supported in SoC testbenches; a `random_axi` stimulus class is derived from a generic stimulus base class to randomize and convert generic commands into AXI commands. Bug hunting SoC designs to achieve full functional coverage closure
[5] Some open-source and proprietary RISC-V cores (e.g., XuanTie C910) use non-standard AXI protocol extensions alongside custom interrupt and debug interfaces; achieving standard compliance is an explicit design goal when integrating such cores into an SoC. Ramping Up Open-Source RISC-V Cores: Assessing the Energy Efficiency of Superscalar, Out-of-Order Execution
[6] In modern SoCs, the AXI protocol exhibits security vulnerabilities that enable partial or complete DoS through protocol-violation attacks via header-field manipulation and systematic malicious operations, and existing countermeasures lack dedicated real-time protocol semantic analysis. IMS: Intelligent Hardware Monitoring System for Secure SoCs
[7] An Intelligent Monitoring System (IMS) using a quantization-optimized neural network achieves 98.7% detection accuracy with <=3% latency overhead and >2.5 million inferences/s, and when integrated into a RISC-V SoC on an AMD Zynq UltraScale+ MPSoC ZCU104 board uses approximately 9.04% LUTs, 0.23% DSP slices, and 0.70% flip-flops with negligible impact on achievable frequency. IMS: Intelligent Hardware Monitoring System for Secure SoCs
[8] Constrained-random AXI traffic exposes swapped control signals between modules, latency inconsistencies versus architecture (causing FIFO/TDM overrun/underrun errors and jitter-buffer voice quality degradation), which require buffer-depth or clock-frequency adjustments. Bug hunting SoC designs to achieve full functional coverage closure
[9] Recommended AXI-based verification setup includes weight-based control for transaction number/size and type, randomized inter-master delays, enabled monitors and checkers, back-door register access for bulk DUT register operations, and coverage sampling with exclude lists. Bug hunting SoC designs to achieve full functional coverage closure