Physically-Aware Preemptive Virtual Channels for Deadlock-Free AXI Networks-on-Chip
Abstract: As many-core Systems-on-Chip (SoCs) continue to scale, Networks-on-Chip (NoCs) must sustain increasingly high memory bandwidth while preserving deadlock freedom. In AXI4 systems, protocol-level dependencies between read and write traffic can create circular waits at the network endpoints, even when the routing algorithm itself is deadlock-free. Decoupling these traffic classes avoids such dependencies, but exposes a key implementation trade-off: multiplane NoCs duplicate wide physical links and increase routing pressure, whereas conventional Virtual Channel (VC) routers add substantial control complexity, area, and timing overhead. This work revisits this trade-off for modern wide-link NoCs. We evaluate four deadlock-free AXI4 traffic-class separation schemes: a multiplane baseline and three lightweight VC-based designs. Among these designs, we propose Preemptive VCs, a physically-aware architecture that can save up to 76% of link resources with comparable frequency and only 3% router area overhead relative to the multiplane design.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
Imagine a huge city built inside a computer chip. The “roads” connect lots of tiny computing neighborhoods so they can send data to each other. This road system is called a Network‑on‑Chip (NoC). Many modern chips move a lot of data very quickly, especially for AI, so these roads have to be very wide and fast.
But there’s a problem: traffic jams that never clear—called deadlocks—can happen when “read” data and “write” data block each other. This paper shows a new way to keep those jams from ever happening, without having to build a second set of giant roads. The new method is called “Preemptive Virtual Channels.”
What questions were the researchers asking?
- How can we stop deadlocks between read and write traffic in AXI4‑based NoCs? (AXI4 is a common set of rules for how parts of a chip talk to each other.)
- Can we do this without doubling the number of very wide, expensive “roads” inside the chip?
- Is there a simpler, lighter design that keeps speed high, uses less wiring, and doesn’t make the routers (the chip’s “intersections”) too big?
How did they study it?
Think of data moving through the chip like trucks driving on highways:
- Read trucks bring data back.
- Write trucks deliver data to memory.
- Deadlock is like four trucks blocking each other at an intersection: each waits for another to move, and no one can go.
To prevent this, you can separate the two kinds of trucks so they don’t block each other. The team tested four ways to do that:
- Multiplane: Build two separate highways—one only for read trucks and one only for write trucks. Simple idea, but you pay for a whole extra wide road.
- Naive Virtual Channels: Keep one highway but paint two lanes on it—one lane for reads, one for writes. However, this version needed the traffic lights at one intersection to react instantly to the next one far away. That long “walkie‑talkie” path slowed everything down.
- Credit‑Based Virtual Channels: Still one highway with two lanes, but use “parking tickets” (credits) to make sure there’s room at the next intersection before a truck drives forward. This fixes timing but needs extra parking spaces (bigger buffers) to keep full speed.
- Preemptive Virtual Channels (their new idea): One highway, two lanes, and a smart rule: if a truck can’t unload at the next exit right now, the lane is immediately given to a different truck that can. In other words, the current truck can be preempted (politely asked to wait) so another truck uses the road this cycle. This keeps traffic flowing without needing a second highway or extra parking.
They built these four versions into an open‑source NoC (FlooNoC), tested performance in detailed simulations, and used real chip‑design tools in a 7‑nanometer process to measure speed, area, and wiring.
What did they find, and why is it important?
- Multiplane (two highways): Fast, but expensive in wiring. It uses a lot more “roads,” which is hard to fit on a chip when links are very wide.
- Naive Virtual Channels: Saved wiring, but ran slower (about 15–16% lower top speed) because of a long control path.
- Credit‑Based Virtual Channels: Fixed the speed, but to stay at full performance it needed deeper buffers (more storage), which increased area a lot. With too-small buffers, it lost about one‑third of throughput (1.5× longer for big transfers).
- Preemptive Virtual Channels (new approach): Hit the best balance.
- Same top speed as the two‑highway design.
- Only about 3% extra router area.
- Saved up to 76% of the wide link routing resources compared to building two highways.
- Same runtime performance as the multiplane approach in system tests.
Why this matters: Modern AI chips use very wide links (like 512–1024 bits) to move huge amounts of data. Duplicating those links is extremely costly in wiring and layout. The new method avoids most of that cost while keeping speed and reliability.
What’s the bigger impact?
Chips are getting bigger and more complex, with tons of data flowing around. The Preemptive Virtual Channels design:
- Helps avoid deadlocks without doubling the widest, most expensive wires.
- Keeps high performance while using less chip area and fewer routing tracks.
- Makes it easier to build large, accelerator‑heavy systems (like AI processors) that must move data quickly and reliably.
- Can reduce design difficulty, cost, and power by lowering wiring pressure, which is a major challenge in advanced chip designs.
In simple terms: it’s a smarter way to share a single big highway between two kinds of traffic so nothing gets stuck, the road stays fast, and the chip doesn’t need a massive (and costly) second road.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper leaves several aspects unaddressed that future work could concretely investigate:
- Formal liveness and safety guarantees: Provide a formal proof (e.g., using resource allocation graphs, model checking, or temporal logic) that Preemptive VCs ensure deadlock freedom and lossless operation for arbitrary AXI4-compliant endpoint behaviors, beyond the illustrative argument based on Coffman’s conditions.
- Starvation and fairness analysis: Quantify whether round-robin with preemption can lead to starvation or unfair latency for one traffic class under persistent backpressure or asymmetric load; characterize worst-case service latency and fairness bounds.
- Generality beyond two classes: Evaluate scalability when separating more than two traffic classes (e.g., QoS tiers, control vs data, coherence messages); assess arbitration complexity, timing closure, and area as the number of VCs increases.
- End-to-end AXI4 compliance under stress: Verify that per-flit preemption does not violate AXI4 ordering/contiguity rules (e.g., write burst contiguity, read data return ordering per ID) across diverse slave/NI configurations and interleaving policies.
- Interaction with coherence protocols: Determine whether the proposed scheme generalizes to ACE/CHI or other cache-coherent fabrics and identify the minimum number of virtual networks/VCs needed for specific coherence protocols and message classes.
- Sensitivity to physical parameters: Sweep link widths (e.g., 256–1024 bits), tile-to-tile distances, and wire RC parasitics to quantify timing/area/routing-resource robustness; evaluate whether conclusions hold for larger tiles, lower-diameter topologies with long bypasses, or retimed/pipelined links.
- Power and energy characterization: Report dynamic/static power and energy/bit for all schemes, including toggle activity from preemption/arbitration and extra buffering; compare energy efficiency against multiplanes at iso-throughput.
- Network-level performance under diverse traffic: Go beyond the single broadcast benchmark to include uniform random, hotspot, transpose, and bursty workloads; provide injection-rate vs. throughput/latency curves and head-of-line blocking impacts.
- Multi-hop behavior and jitter: Quantify cumulative latency/jitter and bandwidth utilization across multiple router hops and under path-length variability, especially with flit-level preemption.
- Buffer sizing guidelines for Preemptive VCs: Establish the minimum safe FIFO depths per port/VC to avoid throughput collapse or backpressure pathologies; study the performance/area/power trade-offs of deeper buffers.
- Robustness under faults and resilience features: Analyze behavior with soft errors, transient link stalls, ECC-protected links, and link failures; assess whether preemption interacts safely with retry/retransmission or fault isolation mechanisms.
- Congestion and routability at system scale: Perform full-chip (or large mesh) PnR and global routing to validate the claimed routing-resource savings under real floorplans, macro placements, and congestion hot spots.
- Technology and PVT portability: Evaluate across additional nodes (e.g., 12/5 nm) and PVT corners with realistic OCV/IR-drop/crosstalk sign-off to ensure findings are not specific to a single 7 nm SS corner.
- Clocking and CDC scenarios: Assess feasibility with multi-clock domains, DVFS islands, and asynchronous bridges; define how preemptive valid/ready semantics and metastability concerns are handled across CDC boundaries.
- QoS and priority support: Extend arbitration to enforce QoS/latency guarantees (e.g., priorities, bandwidth reservations) while retaining deadlock freedom; quantify cost and fairness impacts.
- Impact on packetization/granularity: Examine whether flit-level preemption affects packet reassembly latency or increases reordering buffers at NIs; evaluate overheads for large bursts vs. small messages.
- Comparison to optimized VC microarchitectures: Implement and measure shared-switch VC routers (rather than replicated switches) and other reduced-complexity VC designs to determine if Preemptive VCs remain optimal in PPA.
- Interactions with adaptive routing: Study compatibility with turn-model or fully adaptive routing algorithms and whether preemption affects path diversity or induces new dependency cycles.
- Area decomposition and verification cost: Break down area/timing among crossbars, arbiters, buffers, and control; estimate design/verification complexity and testability differences between multiplane and VC-based schemes.
- Security and side-channel considerations: Analyze whether contention/preemption patterns leak traffic-class or flow information and evaluate mitigations (e.g., traffic shaping or constant-time arbitration).
- Chiplet and off-die links: Investigate applicability over interposers/EMIB/UCIe-style die-to-die links where latency and flow control differ; assess whether preemption remains beneficial with link-layer protocols.
- Integration with reliability/redundancy: Quantify combined effects when link redundancy (e.g., 3× wiring for reliability) is used; determine if Preemptive VCs still deliver large routing savings after redundancy is accounted for.
- Pipeline depth trade-offs: Explore adding optional link/route pipeline stages to relieve timing at very long distances and compare the PPA/throughput impact vs. multiplanes.
- Comprehensive reproducibility: Provide end-to-end scripts (constraints, floorplans, PVT sweeps, traffic generators) to allow independent replication and extension of the physical and performance results.
Practical Applications
Overview
Based on the paper’s findings, the Preemptive Virtual Channels (VCs) architecture offers a practical way to achieve AXI4 protocol-level deadlock freedom without duplicating wide NoC links, yielding up to 76% routing-resource savings at comparable frequency and ~3% router area overhead (vs. multiplane designs). Below are actionable applications across sectors, organized by deployment readiness. Each item notes relevant sectors, potential tools/products/workflows, and assumptions/dependencies that affect feasibility.
Immediate Applications
- AXI4 NoC IP upgrades to reduce routing congestion
- Sectors: Semiconductor IP, SoC design, AI accelerators (datacenter and edge), GPUs
- What to do: Replace multiplane duplication of wide read/write data links with Preemptive VCs in AXI4-compliant NoCs (e.g., FlooNoC); statically map AXI read/write to VCs; deploy round-robin arbitration with preemption.
- Tools/products/workflows: Integrate the provided RTL (FlooNoC v0.8.0 release), update network interfaces to tag read/write channels to separate VCs; add simple per-VC valid/ready signals; maintain single shared wide data link; use standard physical design flows and constraints to route a few extra control wires; reuse existing AXI-based verification testbenches.
- Assumptions/dependencies: AXI4 endpoints may couple read and write traffic (e.g., DMA read-then-write pipelines); wormhole NoC; evaluation at ~750 μm inter-router distance in TSMC 7 nm—timing and savings may vary with node, tile size, and metal stack.
- Metal congestion relief in wide-link, AI-oriented NoCs
- Sectors: Datacenter AI SoCs, wafer-scale and die-scale AI fabrics, high-performance embedded SoCs
- What to do: Adopt Preemptive VCs to avoid duplicating 512–1024-bit data links, reducing top-metal track demand and easing routing closure in dense floorplans.
- Tools/products/workflows: Floorplan guidelines to keep the (narrow) extra control signals short; metal-track budgeting with physical design teams; incremental place-and-route with congestion-driven optimization.
- Assumptions/dependencies: Benefits grow with link width and redundancy requirements; congestion improvements may translate to higher yield and/or shorter design cycles.
- Low-overhead deadlock avoidance in AXI-based tiled SoCs
- Sectors: Edge AI, robotics, automotive SoCs, embedded compute (RISC-V/ARM)
- What to do: Use Preemptive VCs to decouple AXI read/write data paths, avoiding protocol-level circular waits without constraining endpoint (e.g., DMA) behavior.
- Tools/products/workflows: Integrate into existing tile meshes (e.g., Snitch-cluster-based SoCs); run cycle-accurate simulations (e.g., QuestaSim) with representative traffic patterns (broadcast, all-to-all).
- Assumptions/dependencies: Static two-class separation (read vs. write) is sufficient; arbitration fairness (round-robin) prevents starvation under typical workloads.
- Timing closure improvements by removing long ready-valid paths
- Sectors: ASIC physical design, EDA
- What to do: Replace naive valid/ready VC designs (with long ready→valid combinational paths) with the Preemptive scheme to register backpressure and prevent critical path explosion across tile widths.
- Tools/products/workflows: STA and sign-off flows leveraging registered ready signals; timing-driven placement; formal equivalence and lint checks for modified router microarchitecture.
- Assumptions/dependencies: Tile widths and topologies that make long combinational paths dominant; Preemptive arbitration integrated in the router pipeline.
- Open-source research and teaching platforms
- Sectors: Academia, open-hardware communities
- What to do: Use the released implementations to study deadlock-avoidance schemes and physically aware NoC microarchitectures; run PPA comparisons (area/timing/routing resources) across nodes and link widths.
- Tools/products/workflows: FlooNoC v0.8.0 RTL, reference SoC integration (Gwaihir repo branch), open EDA flows (or commercial tools where available), reproducible scripts for DSE.
- Assumptions/dependencies: Access to synthesis/P&R tools (open or commercial); AXI4-based platforms preferred for drop-in evaluation.
- Embedded/IoT SoCs: performance/watt gains without extra metal
- Sectors: Consumer IoT, smart home, wearables
- What to do: Deploy Preemptive VCs to achieve deadlock freedom with minimal area/power impact and without doubling wide links, contributing to better energy efficiency and potentially extending device battery life.
- Tools/products/workflows: Integrate into existing AXI-based fabrics; lightweight verification of read/write separation under bursty DMA traffic.
- Assumptions/dependencies: Benefits scale with link width and metal congestion; smaller designs gain less from routing-resource savings but still avoid deadlocks cleanly.
- Automotive and safety-oriented SoCs (redundancy-aware interconnects)
- Sectors: Automotive ADAS/AI, industrial control
- What to do: Use Preemptive VCs to offset the routing cost of interconnect redundancy (e.g., triple-redundant links), by avoiding additional wide-link duplication for traffic-class separation.
- Tools/products/workflows: Safety cases integrating preemptive arbitration and fault-tolerant routing; redundancy planning with fewer physical data planes.
- Assumptions/dependencies: Safety goals still require redundancy/ECC; Preemptive VCs reduce incremental routing overhead but do not replace safety mechanisms.
Long-Term Applications
- Generalization to multi-class separation beyond read/write
- Sectors: Coherent SoCs (ACE/CHI), multi-tenant accelerators, GPUs
- What to build: Extend Preemptive VCs to more protocol classes (requests, responses, coherence probes/acks, interrupts) with formal deadlock-free guarantees and QoS-aware arbitration.
- Dependencies: Additional VCs per class; formal verification of deadlock freedom and fairness; potential small buffers to handle deep class hierarchies.
- Chiplet and die-to-die interconnect co-design
- Sectors: Chiplet ecosystems (UCIe/BoW carriers), advanced packaging
- What to build: Apply preemptive VC semantics across die-to-die links to reduce bump counts and package routing pressure versus multiplane solutions; co-design adapters that preserve preemption across clock/power domains.
- Dependencies: Robust flow control over higher-latency D2D links; CDC and error handling; interoperability with chiplet standards.
- Automated NoC synthesis and floorplan-aware DSE
- Sectors: EDA tools, NoC IP vendors
- What to build: Tools that co-explore VC count, arbitration policy, and metal budgets; automatically choose between multiplanes and preemptive VCs per link given congestion and timing targets.
- Dependencies: Accurate physical/cost models; integration with P&R congestion estimators; user constraints for critical paths and class separation.
- Reliability- and fault-tolerance-aware preemptive routing
- Sectors: Automotive, aerospace, high-availability datacenter
- What to build: Combine preemptive VCs with link-level fault detection, rerouting, and redundancy management to minimize metal cost while sustaining availability targets.
- Dependencies: In-field monitoring, fast failover; formal guarantees for progress under fault conditions.
- Security and isolation via class-aware preemption
- Sectors: Multi-tenant accelerators, secure SoCs
- What to build: Use class separation and preemption to reduce head-of-line blocking and mitigate microarchitectural side channels across tenants; integrate with partitioning and QoS.
- Dependencies: Threat modeling; formal analysis for interference channels; policy-driven arbitration and bandwidth caps.
- Optical/3D NoCs and emerging interconnects
- Sectors: Advanced research (silicon photonics, monolithic 3D)
- What to build: Apply preemptive VCs where link replication is extremely costly (waveguides/TSVs); leverage preemption to share scarce physical channels across classes.
- Dependencies: New physical layers, link latencies, and error characteristics; adapted arbitration timing.
- Standardization and guidelines for AXI-class separation
- Sectors: Industry consortia, IP providers
- What to build: Design recommendations for AXI-capable endpoints and NoCs to use preemptive VCs for class separation as a default pattern to avoid protocol-level deadlocks without multiplanes.
- Dependencies: Alignment with AMBA ecosystem; IP provider support and verification collateral.
- Curriculum and workforce development
- Sectors: Academia, training programs
- What to build: Courses and labs on physically aware NoC design, emphasizing the area/timing/routing trade-offs and deadlock avoidance via preemptive VCs; benchmarks and open-source projects for hands-on education.
- Dependencies: Teaching materials; open PDKs or academic access to EDA; sustained community support.
Notes on Feasibility and Assumptions (across applications)
- Reported savings are measured on FlooNoC-based routers at ~512-bit link widths, TSMC 7 nm, and ~750 μm router spacing; actual gains depend on process, floorplan, and link width.
- Preemptive VCs are validated for two-class (read/write) static mapping with round-robin arbitration; extending to more classes or adding strict QoS requires additional design and proofs.
- The approach assumes wormhole flow control and AXI4 semantics at the endpoints; different protocols (ACE/CHI/CXL-on-die) need tailored mapping and verification.
- Functional verification must ensure no starvation under pathological traffic; preemption policy tuning may be required for specific workloads.
Glossary
- AXI4: A widely used on-chip, memory‑mapped interconnect protocol with separate read/write channels and handshake signals. "In AXI4 systems, protocol-level dependencies between read and write traffic can create circular waits at the network endpoints"
- Area–Timing (AT) plots: Graphs illustrating the trade-off between circuit area and achievable timing/frequency. "AT plots of the analyzed deadlock-free designs."
- Backpressure: A flow-control mechanism where the receiver throttles the sender to prevent buffer overflow. "the receiver to apply independent backpressure for each traffic class."
- Bandwidth utilization: The fraction of the theoretical link bandwidth that is effectively achieved by a design. "routing resource usage and bandwidth utilization for all designs in TSMC \SI{7}{\nano\meter}"
- Beat (AXI4 beat): The smallest data unit transferred per cycle within an AXI burst. "As the read data returns, each AXI4 beat #1{2} is immediately forwarded into a write burst"
- Coffman's hold and wait condition: A deadlock condition where processes hold resources while waiting for others; breaking it helps avoid deadlock. "To break Coffman's hold and wait condition, data is injected onto the shared physical link only when the corresponding downstream receiver is ready"
- Coffman's mutual exclusion condition: A deadlock condition requiring resources that cannot be shared; breaking it helps avoid deadlock. "breaking Coffman's mutual exclusion condition."
- Coffman's no preemption condition: A deadlock condition where resources cannot be forcibly reallocated; breaking it helps avoid deadlock. "prior \gls{vc} designs have not targeted Coffman's no preemption condition."
- Combinational dependency: A zero-latency (combinational) signal path that can extend critical paths and hurt timing. "this introduces a ready-to-valid combinational dependency"
- CreditBased protocol: A flow-control scheme where the sender tracks available downstream buffer credits and transmits only when credits are available. "a CreditBased protocol can be adopted by extending the router interface with a credit signal"
- Crossbar: A switching fabric that connects multiple masters and slaves, enabling concurrent transfers. "through the AXI4 crossbar #1{4}."
- Deterministic XY routing: A dimension‑order routing algorithm for mesh networks that routes along X then Y (or vice versa) deterministically. "even when deterministic XY routing is employed"
- Direct Memory Access (DMA) engine: Hardware that moves data between memories/peripherals without CPU intervention. "a DMA engine (AXI4 initiator) issues a read burst request to a remote memory"
- Flit: A flow-control unit; the smallest piece of a packet moved through a wormhole router. "A flit may occupy the shared link only if the corresponding downstream buffer has free space"
- FlooNoC: An open-source AXI4‑compliant Network‑on‑Chip with wide physical links and multistream support. "FlooNoC stands out as the first open-source AXI4-compliant \gls{noc}"
- Fusion Compiler: A commercial electronic design automation tool for logic synthesis and physical implementation. "using Fusion Compiler 2024.09 under worst-case conditions"
- Inter-router wire delay: The propagation delay across the physical wires connecting neighboring routers. "capturing inter-router wire delay and excluding unrelated cluster logic."
- Mesh SoC: A system-on-chip whose tiles/cores are connected in a 2D mesh topology. "we integrate them into a mesh \gls{soc}"
- Multiplane: An approach using multiple physical networks/planes to separate traffic classes and avoid protocol-level blocking. "The baseline solution extends the multiplane approach adopted in FlooNoC."
- Network-on-Chip (NoC): An on‑chip packet‑switched interconnect fabric used to connect many cores and IP blocks. "As many-core \glspl{soc} continue to scale, \glspl{noc} must sustain increasingly high memory bandwidth"
- Place and route (P&R): Physical design steps that place standard cells and route interconnects to meet timing/area constraints. "we place and route two FlooNoC routers at a representative tile-to-tile distance"
- Preemptive VCs: A virtual-channel scheme where link ownership can be reallocated if the current stream cannot progress, breaking no‑preemption effects without extra buffering. "we propose Preemptive \glspl{vc}, a physically-aware architecture"
- Ready/valid handshake: A two‑signal handshake for backpressure flow control, where data transfers occur when both ready and valid are high. "We first evaluate a Naive valid/ready implementation"
- Round-robin arbitration: An arbitration policy that cyclically grants service to requesters to ensure fairness. "Link ownership is selected through round-robin arbitration among the valid streams"
- Router datapath: The data‑handling pipeline and switching logic inside a network router. "each with its own tile-to-tile physical link #1{1} and router datapath."
- Routing pressure: The demand for routing resources (wires/tracks) that can complicate physical implementation. "multiplane \glspl{noc} duplicate wide physical links and increase routing pressure"
- Scratch‑Pad Memory (SPM): A software‑managed, low‑latency on‑chip memory local to a core or tile. "directed to a local L1 \gls{spm} (AXI4 target)"
- Tile-to-tile link: The physical interconnect between adjacent tiles in a tiled many‑core SoC. "the wide tile-to-tile link, which doubles the number of wide pins and routed tracks"
- TSMC 7 nm technology: A semiconductor manufacturing node used for logic implementation in the study. "TSMC \SI{7}{\nano\meter} technology using Fusion Compiler 2024.09"
- Virtual Channels (VCs): Multiple logical queues sharing the same physical link to separate flows and avoid head‑of‑line blocking/deadlocks. "One solution is to use \glspl{vc}"
- Wormhole routing: A routing technique where packets are divided into flits that traverse routers with minimal buffering, holding channels as they advance. "the interaction between wormhole-routed AXI4 transactions"
- Worst-case conditions (SS, −40°C, 0.675 V): PVT corner settings (slow process, low temperature/voltage) used for conservative timing closure. "using Fusion Compiler 2024.09 under worst-case conditions (SS, C, \SI{0.675}{\volt})"
Collections
Sign up for free to add this paper to one or more collections.