PaperlayerView exact revision on arXiv

Source-linked AI summary

Scalable AXI4 Transaction Monitoring for Mixed-Criticality SoCs: From Phase-Level Precision to ID-Level Efficiency

Chaoqun Liang, Thomas Benz, Alessandro Ottaviano, Michael Rogenmoser, Luca Benini, Angelo Garofalo, Davide Rossi

arXiv:2608.30435v1cs.AR

TL;DR

AXI4-based mixed-criticality SoCs lack protocol-level timeouts, leaving stalled transactions vulnerable to deadlock and missed deadlines. The paper introduces a configurable, non-intrusive TMU with PLT, CLT, and ILT variants plus cut-and-drain recovery. In evaluation, the variants detected all faults manifesting as AXI4 protocol or liveness violations, while trading area against latency and localization precision.

  • Problem

    AXI4 lacks a mandatory timeout mechanism, so stalled subordinate transactions may never complete and can contribute to deadlocks and missed real-time deadlines.

  • Method

    The paper develops a configurable non-intrusive AXI4 TMU with three monitoring granularities and cut-and-drain isolation for recovery.

  • Results

    Fault-injection campaigns on a RISC-V SoC found no escaped fault among AXI4 protocol or liveness violations, with detection latencies bounded by theoretical WCDT predictions.

  • Takeaways & Limitations

    PLT, CLT, and ILT define a design space for aligning monitoring overhead with subordinate criticality and safety-certification requirements.

Abstract

from arXiv · show

Mixed-criticality Systems-on-Chip (SoCs) with on-chip interconnects based on the AXI4 open standard protocol lack a protocol-level timeout mechanism, exposing systems to deadlocks and missed real-time deadlines when subordinate devices or managers fail or stall due to hardware faults, radiation-induced upsets, or software errors. This work presents a configurable hardware intellectual property (IP), non-intrusive in fault-free operation, that detects AXI4 protocol violations and timing faults at runtime and restores interconnect liveness through a cut-and- drain isolation mechanism. To address the fundamental trade-off between monitoring granularity and area cost, we introduce three designs at decreasing monitoring granularity: Phase-Level Track-ing (PLT), which provides cycle-accurate fault localization across individual protocol phases; Channel-Level Tracking (CLT), which coalesces per-phase monitors into channel-level supervision; and ID-Level Tracking (ILT), which achieves sub-linear area scaling by monitoring only per-ID transaction boundaries. Synthesized in GlobalFoundries 12 nm technology, CLT reduces area by 36.7% relative to PLT while preserving worst-case detection bounds at a minimal detection latency overhead, whereas ILT achieves an 89.2% area reduction suitable for tightly constrained deployments at the cost of a 3.7x higher median detection latency with coarser fault localization. Fault injection campaigns on a RISC-V SoC across 1.2 million scenarios confirm that no fault manifesting as an AXI4 protocol or liveness violation escaped detection, with observed detection latencies consistently bounded by theoretical worst-case predictions.

I. INTRODUCTION

Mixed-criticality AXI4 SoCs lack mandatory timeout supervision, allowing stalled subordinate transactions to propagate deadlocks and missed deadlines. This paper addresses the gap with a configurable TMU and three monitoring granularities that balance detection, recovery, area, and diagnostic capability.

  • Motivation: AXI4 defines no mandatory timeout, so permanently failed and merely slow subordinates cannot be distinguished at the protocol level.Outstanding transactions may never complete, allowing deadlock propagation upstream and potentially causing missed real-time deadlines.
  • Related Work: Prior approaches separately address compliance checking, coarse-grained timeout supervision, throughput monitoring, or intentional security violations rather than the full fault-detection and recovery problem.Protocol checkers lack timeout supervision and recovery, while timeout mechanisms lack per-phase visibility and multitransaction support.
  • Design Challenges: The TMU must provide temporal supervision, fault containment, resource efficiency, and diagnostic observability for interleaved, out-of-order AXI4 transactions.These four challenges define the design requirements for monitoring and recovery across mixed-criticality SoCs.
  • Contributions: Three variants—PLT, CLT, and ILT—span decreasing monitoring granularity to trade capability and diagnostic precision against implementation complexity.The variants let designers align monitoring overhead with subordinate criticality and safety-certification requirements.
  • Contributions: The TMU is non-intrusive during fault-free operation and detects manager- and subordinate-originated protocol or timing faults with bounded recovery.Recovery uses cut-and-drain isolation to restore interconnect liveness after fault detection.
  • Evaluation: RISC-V SoC fault-injection campaigns confirmed that no fault escaped detection within each variant’s detectable class, with empirical latencies consistent with theoretical WCDT bounds.The variants were characterized for coverage, latency, and area scaling in GlobalFoundries 12 nm technology.

A. Transactions, Phases, and Channels

The paper defines AXI4 transfers, transactions, phases, identifiers, and ordering asymmetries that determine the TMU’s monitoring scope and tracking structures. The architecture is a non-intrusive hardware IP whose variants trade monitoring granularity against area overhead.

  • A. Transactions, Phases, and Channels: A transfer is one VALID/READY-handshaked beat, while a transaction spans AXI4 address, data, and response channels across a burst.Burst length is specified by AWLEN or ARLEN, and WLAST or RLAST marks the final beat.
  • A. Transactions, Phases, and Channels: A phase denotes a protocol event or transition used as a semantic boundary for monitoring and timing measurement, not a formal AXI4 specification term.Examples include address issuance, data-beat transfer, and response reception.
  • A. Transactions, Phases, and Channels: AXI4 permits multiple outstanding transactions and out-of-order completion across IDs, while same-ID responses remain ordered and W-channel data follows AW issue order.R-channel beats can interleave across IDs because each beat carries RID.
  • C. Fault Model and Scope: The TMU observes AXI4 traffic at the interconnect–subordinate interface, so it detects signaling and progress faults but not faults that leave bus signaling well-formed.Silent data corruption therefore requires complementary end-to-end protection such as ECC.
  • III. Architecture: The TMU monitors in-flight transactions without adding arbitration, buffering, or protocol state to the AXI4 path and without modifying the crossbar microarchitecture.A TMU instance is placed per monitored subordinate and observes both request and response channels.
  • III. Architecture: The three variants address the granularity–area trade-off, ranging from fine-grained per-transaction state to lower-overhead monitoring for constrained SoCs.The design family supports different subordinate criticalities and area or power budgets.

A. Phase-Level Tracking (PLT)

PLT provides the finest monitoring granularity by supervising discrete AXI4 protocol phases with independent timeout tracking. Its architecture combines ID compression, dynamic transaction tracking, and ordering-aware structures to support concurrent traffic.

  • A. Phase-Level Tracking (PLT): PLT decomposes each AXI4 transaction into discrete protocol phases with independent timeout supervision for precise fault localization.It can localize faults to address handshakes, data transfers, or response completion and supports diagnostic logging.
  • A. Phase-Level Tracking (PLT): The ID Remapper compresses sparse external AXI4 IDs into a dense internal space bounded by MaxUniqIDs, reducing storage and operand width.Only ID fields are compressed and decompressed; other signals pass through transparently.

Pre-Enqueue Monitoring:

Pre-enqueue monitoring uses lightweight channel watchdogs before allocating transaction-tracking state, after which the TMU dynamically organizes transactions by ID and protocol ordering.

  • Pre-Enqueue Monitoring:: Pre-enqueue watchdogs Cw0 and Cr0 monitor AW/AR handshake latency without consuming transaction-tracking entries.They prevent sustained backpressure from exhausting tracking capacity before address acceptance.
  • Pre-Enqueue Monitoring:: The Linked Queue Architecture dynamically allocates shared transaction slots while preserving per-ID ordering and supporting arbitrary completion order across IDs.It combines a flat Transaction Table, per-ID chains, and a W-Ownership FIFO for serialized W-channel data.
  • Pre-Enqueue Monitoring:: The TMU parameterizes capacity with MaxUniqIDs, TxnPerUniqID, and MaxOutstdTxns.These parameters set ID-bucket count, per-bucket depth, and total outstanding write-transaction capacity.
  • Pre-Enqueue Monitoring:: Dedicated phase counters supervise transactions after enqueue, with shared W-channel data counters and per-ID R-channel counters matching AXI4 ordering constraints.The dual-counter scheme separates per-beat liveness detection from monotonic burst-length validation.
  • Pre-Enqueue Monitoring:: A prescaled timebase reduces counter bit-width while sticky event sampling prevents transitions between coarse ticks from being missed.The trade-off is reduced detection resolution in exchange for area efficiency.

Dequeue and Protocol Validation:

Dequeue logic enforces per-ID completion order while allowing responses across IDs to complete out of order, and fault recovery fabricates compliant responses after isolating the affected path.

  • Dequeue and Protocol Validation:: On B handshake, BID selects an ID Queue bucket, validates the head transaction’s burst length, frees its slot, and advances the per-ID chain.This enforces W2/R2 ordering while supporting cross-ID response reordering.
  • Dequeue and Protocol Validation:: The cut phase blocks new AW and AR requests, while the drain phase fabricates protocol-compliant completions for pending transactions.Fabricated write responses use BRESP=SLVERR, while pending reads receive remaining beats with RRESP=SLVERR and correct remapped IDs.
  • Dequeue and Protocol Validation:: PLT and CLT must complete full read bursts with RLAST on the final beat, whereas ILT retires each pending read with a single RLAST beat.Writes require only one B response for retirement.
  • Dequeue and Protocol Validation:: The fault logger captures the first fault’s transaction ID, direction, phase, detection latency, and fault type until software clears fault_clear.This preserves the earliest fault context for software diagnosis.

Programming Model:

The programming model exposes configurable timeout and latency controls across monitoring variants, while progressively reducing counter and tracking complexity from PLT through CLT to ILT.

  • Programming Model:: Timeout budgets and the prescaler are runtime-configurable, while latency[i] records recent phase-counter detection latency for budget tuning.Budgets may be set online from representative traffic or derived offline.
  • Programming Model:: CLT coalesces PLT’s phase counters into seven channel-level counters while retaining the foundational ID Remapper and LQA.Its fault status reports coarser channel-granularity diagnostics.
  • Programming Model:: ILT reduces area complexity to O(NID) by monitoring per-ID completion boundaries instead of per-transaction state.This trades away detection granularity and increases detection latency relative to finer-grained designs.
  • Programming Model:: ILT removes the Transaction Table and W-Ownership FIFO, retaining a simplified ID Queue with per-ID outstanding counts and timeout counters.The queue increments on address handshakes and decrements on completion handshakes.
  • Programming Model:: ILT’s write completion counter independently monitors each ID but does not support burst-length validation or WLAST protocol checking.Its read counter detects intermediate stalls only when they delay RLAST beyond budget and does not validate ARLEN or premature or excess RLAST.

IV. WORST-CASE DETECTION TIME ANALYSIS

Worst-Case Detection Time is defined as the observable fault exposure window from transaction entry into the AXI domain until the TMU flags the violation and initiates recovery.

  • IV. WORST-CASE DETECTION TIME ANALYSIS: Worst-Case Detection Time is governed by monitoring granularity and configured timeout budgets.Budgets are controlled through TMU registers at startup or runtime.
  • IV. WORST-CASE DETECTION TIME ANALYSIS: The effective detection window begins at observable transaction initiation because faults may remain dormant before manifesting at the bus interface.tstart corresponds to AWVALID or ARVALID assertion, while internal tfault may be unobservable.

A. Phase-Level Tracking (PLT)

PLT supervises each AXI4 protocol phase independently, minimizing the fault exposure window, while CLT and ILT aggregate phases into coarser monitoring points with progressively larger worst-case detection windows.

  • A. Phase-Level Tracking (PLT): PLT detects a fault immediately when the failing phase’s individual timeout budget expires.Its phase-specific monitoring provides the finest fault localization among the three architectures.
  • A. Phase-Level Tracking (PLT): The PLT worst-case detection time sums nominal antecedent-phase completion times with the failing phase’s timeout threshold.The overall bound takes the maximum over all possible failing phases.
  • A. Phase-Level Tracking (PLT): PLT yields the lowest fault exposure window because each threshold is bounded to the physical latency requirement of its individual phase.This phase-level precision is the basis for its diagnostic advantage over coarser designs.
  • A. Phase-Level Tracking (PLT): CLT increases the worst-case detection time because each unified channel budget must cover the slowest PLT phase collapsed into that channel.The reduced number of monitoring points trades phase precision for a larger timeout budget.
  • A. Phase-Level Tracking (PLT): ILT monitors only address handshakes and final B/RLAST completions, using a single address-to-completion budget without intermediate-phase visibility.Its completion threshold therefore exceeds any individual PLT phase threshold and produces the largest worst-case detection time.

D. Cut-and-Drain Time

Cut-and-drain recovery bounds liveness restoration by combining fault detection time with a bounded drain interval, while its practical guarantee covers the hardware path rather than software recovery.

  • D. Cut-and-Drain Time: The liveness-restoration bound combines worst-case detection time with the transaction-drain time after isolation begins.The cut admits no new requests, fixing the drain set at recovery start.
  • D. Cut-and-Drain Time: Write and read traffic drain concurrently, but reads can require completion of full bursts while writes use fabricated error responses after residual data absorption.Write data absorption costs at most Lmax cycles, whereas pending reads may continue through all ARLEN+1 beats.
  • D. Cut-and-Drain Time: ILT bounds drain time independently of burst length by retiring each pending read with a single RLAST-asserting beat.This reduced-state behavior requires managers to treat RLAST as the transaction boundary.
  • D. Cut-and-Drain Time: The hardware liveness bound is fixed at design time and independent of subordinate responsiveness because responses are fabricated locally.Software recovery steps such as interrupt handling, reset sequencing, and driver reinitialization are outside the bound.

A. Area Overhead and Scaling Characteristics

Area scales with monitoring granularity and concurrency: PLT and CLT depend on total outstanding transactions, whereas ILT depends only on unique IDs, reducing area substantially as per-ID depth grows.

  • A. Area Overhead and Scaling Characteristics: O(NID × D) area scaling applies to PLT and CLT, while ILT achieves O(NID) scaling by decoupling area from per-ID transaction depth D.The variants were synthesized in GlobalFoundries 12 nm FinFET technology across configurations spanning 16 to 256 outstanding transactions per direction.
  • A. Area Overhead and Scaling Characteristics: PLT grows from 11.4 kGE to 167.7 kGE, while CLT grows from 6.9 kGE to 112.3 kGE across the evaluated configurations.CLT maintains a 33.1% to 39.5% reduction over PLT across those configurations.
  • A. Area Overhead and Scaling Characteristics: ILT grows only 3.0×, from 2.6 kGE to 7.8 kGE, for the same 16× capacity increase and saves 77.2% to 95.3% over PLT.The area advantage comes with a 3.7× higher median detection latency at 4 × 16.
  • A. Area Overhead and Scaling Characteristics: At 4 × 16, PLT occupies 40.6 kGE, CLT 25.7 kGE, and ILT 4.4 kGE.CLT consolidates per-phase state into channel watchers, while ILT monitors only 8 IDs rather than 128 concurrent transactions.
  • A. Area Overhead and Scaling Characteristics: All 15 configurations close the 1 GHz target with positive slack, with a minimum achieved Fmax of 1.33 GHz.Power is reported at the 1 GHz iso-frequency point using dynamic-power back-annotation from in-system iDMA traffic.

Comparative Fault Detection Coverage:

The three TMU architectures preserve detection coverage for observable AXI4 protocol and liveness faults, while granularity shapes latency distributions and fault localization. CLT retains worst-case bounds with modest latency shifts, whereas ILT relies on coarser transaction-boundary supervision.

  • Coverage: 0.41% of HyperBus faults shift from detectable to undetectable under ILT because endpoint-only monitoring misses intermediate faults that do not stall transaction boundaries.Missing data beats within a burst can fall outside ILT’s observability window.
  • Coverage: No false detections occurred in the controlled campaign because thresholds were set above nominal fault-free phase latencies.Threshold margins increase detection bounds additively, creating a schedulability trade-off outside this paper’s scope.
  • Latency behavior: PLT detects handshake faults deterministically at phase boundaries, while data-phase liveness detections vary below the WCDT bound and remain within the 314-cycle configured limit.Backpressure faults can start the B-response timer early, but detection remains bounded.
  • Latency behavior: CLT shifts some early data-phase detections from 10 and 18 cycles to 43 cycles while preserving the dominant 225- and 314-cycle worst-case bounds.This validates minimal detection-latency overhead alongside the reported area reduction.
  • Latency behavior: ILT’s median latency is 3.7× higher than PLT, with detections concentrated at the 712-cycle read and 962-cycle write completion boundaries.Its density profile reflects reliance on end-to-end transaction timeouts rather than intra-transaction monitoring.

Area-Latency Design Space:

The TMU variants define an area-latency-diagnostic design space: PLT maximizes localization, CLT offers a balanced deployment point, and ILT minimizes area for constrained endpoints. Relative to prior solutions, the framework combines bounded detection and recovery with selectable monitoring granularity.

  • Area-Latency Design Space: CLT holds median latency to 213 cycles while reducing area by 36.7% relative to PLT and retaining channel-level diagnostic visibility.The paper identifies CLT as the preferred point for most deployments.
  • Area-Latency Design Space: ILT trades a 712-cycle median for an 89.2% area reduction, targeting tightly constrained endpoints where transaction-level recovery is sufficient.This design sacrifices phase-level diagnostics.
  • Area-Latency Design Space: PLT minimizes the fault exposure window at 191 cycles while providing per-phase localization, fault-source identification, and detailed latency logging.Its diagnostic richness comes at maximum hardware cost.
  • Related Work: The framework addresses a gap left by performance monitors, protocol checkers, access-control solutions, and coarse timeout mechanisms, each covering only subsets of safety-critical monitoring requirements.The comparison spans fault detection, timing, liveness, and recovery capabilities.
  • Related Work: ILT provides bounded detection and interconnect recovery in 4.4 kGE, while coarse timeout mechanisms in the comparison lack both capabilities.AXIChecker’s 70.7 kGE figure is not directly comparable because it uses 180 nm technology and has narrower scope.
  • Contribution: The three-tier framework extends prior TMU work with PLT, CLT, and ILT granularity choices plus WCDT analysis validated across 1.2 million fault-injection scenarios.At the 4×16 configuration, PLT reduces area from 108.8 kGE to 40.6 kGE, a 62.7% reduction.
Loading 2608.30435v1…