XAIF: Extensible Accelerator Interface

• XAIF is a standardized and extensible accelerator interface that connects heterogeneous accelerators to the configurable X-HEEP host platform.
• It bundles configurable OBI connections, DMA extensions, interrupts, and power management signals to support diverse accelerator integration styles.
• XAIF reduces bespoke SoC redesign by providing predefined pathways for memory-like, master, and ISA-extension accelerators in ultra-low-power TinyAI systems.

The eXtendible Accelerator InterFace (XAIF) is the accelerator integration mechanism of X-HEEP, an open-source, configurable, and extendible RISC-V platform for ultra-low-power edge applications (TinyAI). In the X-HEEP architecture, XAIF is presented as a standardized accelerator-facing integration interface that enables “straightforward and flexible integration of tightly-coupled accelerators with different area, power, and performance constraints.” Concretely, it “bundles configurable OBI connections (slave and master), DMA extensions, interrupts, and power management control signals,” and, when X-HEEP uses CV32E40X or CV32E40PX, it also includes CORE-V-XIF support for ISA-extension coprocessors. XAIF is therefore not a single narrow port, but a package of integration hooks that allows X-HEEP to act as a host platform for heterogeneous TinyAI systems (Machetti et al., 23 Aug 2025).

1. Motivation and problem setting

XAIF was introduced in response to a recurring integration problem in open-source SoCs: many platforms either do not expose a rich native path for accelerator attachment, or require substantial manual RTL/software changes when adding a custom accelerator. In the X-HEEP paper, the limitations attributed to prior systems include constrained external interfaces, poor support for external interrupts, no integrated power-control path, and lack of native configurability of core, memory, bus, and peripheral subsystems (Machetti et al., 23 Aug 2025).

These limitations are especially restrictive in the target domain of ultra-low-power edge/TinyAI systems, because accelerators can differ sharply in memory access style, control requirements, bandwidth demand, interrupt behavior, and power-management coupling. XAIF is introduced as a single extensible attachment model for these heterogeneous accelerator classes. The practical objective is to reduce bespoke SoC redesign: instead of repeating accelerator-specific integration work, a designer attaches the accelerator through a predefined set of pathways already anticipated by X-HEEP.

The resulting design position is precise. XAIF is not described as a standalone external protocol specification. Rather, it is the native internal integration layer that makes X-HEEP more than a small RISC-V SoC: it is the mechanism through which the platform becomes a configurable host for memory-like accelerators, autonomous masters, and CPU-coupled coprocessors.

2. Architectural role and explicit interface contents

Architecturally, XAIF sits at the boundary between the configurable X-HEEP host and one or more external or custom accelerators. X-HEEP itself is described as comprising a configurable CORE-V CPU, configurable memories, OBI-based buses, peripherals split into main and always-on domains, and extensible accelerator and coprocessor attachment points. XAIF is the interface family that attaches accelerators into that architecture (Machetti et al., 23 Aug 2025).

The paper’s most explicit statement of XAIF’s contents is summarized below.

XAIF element	Function stated in the paper
Configurable OBI slave connection	Control/configuration path for accelerator integration
Configurable OBI master connection	Autonomous access to shared memory resources
DMA extensions	Data movement support, including DMA-mediated integration styles
Interrupts	Standardized event/completion signaling into the host platform
Power management control signals	Coupling to the platform’s power-management mechanisms
CORE-V-XIF support	Optional ISA-extension coprocessor path with CV32E40X/CV32E40PX

The OBI slave side is the natural control path. Through it, the CPU can configure accelerator registers, trigger operation, inspect status, and potentially access accelerator-local memories or command queues. The paper, however, does not provide a register map, address offsets, CSR definition, or software-visible bitfields for XAIF itself. Accordingly, XAIF is specified at the architectural level rather than at the level of a complete programmer’s model.

The OBI master side and the DMA extensions define the data path. The master path allows an accelerator to access shared memory resources directly. The DMA path is particularly important because X-HEEP includes a “smart multi-channel DMA engine, supporting both 1D and 2D transactions,” and accelerators with DMA-compatible access patterns can use “elastic DMA interfaces” to collect data without additional master ports. This is one of the clearest indications that XAIF is intended to support more than one attachment pattern: an accelerator may be a bus master, or it may remain bus-light and rely on DMA-mediated transfers.

Interrupt support is explicit, but the mapping is left abstract. X-HEEP contains both a PLIC in the main peripheral domain and a fast interrupt controller in the always-on domain, yet the paper does not specify whether XAIF interrupts are routed to one, the other, or both, nor whether they are edge-sensitive, level-sensitive, vectored, or software-cleared. The grounded conclusion is simply that XAIF provides a standardized interrupt path from accelerator to host software.

3. Extendibility and supported accelerator classes

XAIF is called “extendible” because it is not tied to one accelerator interaction style. The X-HEEP paper organizes its architectural role around three integration modes: memory-like/slave accelerators, master accelerators, and coprocessors / ISA extensions. In that sense, XAIF is not merely a bus adapter; it is the heterogeneous accelerator integration layer for X-HEEP (Machetti et al., 23 Aug 2025).

Memory-like accelerators are controlled through CPU reads and writes to accelerator-exposed addressable resources, conceptually similar to peripheral or memory-mapped blocks. The paper gives several examples: Blade, NM-Carus, NM-Caesar, ARCANE, and HEEPstor. These examples suggest an integration style in which control is memory-centric and the accelerator may be closely related to memory banks.

Master accelerators autonomously access shared system memory. The examples include OpenEdge CGRA, STRELA, e-GPU, and an Im2Col accelerator. This class is especially informative for XAIF because it covers both direct-master attachment and DMA-assisted operation. The paper explicitly notes that some accelerators can avoid extra master ports by exploiting DMA-based collection.

ISA-extension coprocessors are tightly coupled to the CPU pipeline through CORE-V-XIF when X-HEEP uses CV32E40X or CV32E40PX. The cited examples are Quadrilatero, Coprosit, and ATHOS. This optional path matters because it places coprocessor-style specialization under the same overall integration umbrella as memory-like and autonomous accelerators.

Taken together, these classes show that XAIF’s extendibility comes from composition of interface elements: a slave path for control, a master path for autonomous memory traffic, DMA assistance for structured transfers, interrupt signaling, power-control coupling, and an optional CPU-pipeline extension path. The paper does not reduce XAIF to a single socket or wrapper; it presents a packaged attachment model for accelerators “with varying requirements.”

4. Platform context inside X-HEEP

XAIF cannot be understood independently of the X-HEEP host platform, because its practical behavior depends on the configurable CPU, interconnect, memory system, peripherals, and power domains into which it is inserted. The paper identifies the following supported cores: CV32E20, CV32E40X, CV32E40P, and CV32E40PX. Among these, the XIF-capable cores are CV32E40X and CV32E40PX (Machetti et al., 23 Aug 2025).

The bus protocol is OBI (Open Bus Interface), and the bus topology can be configured as one-at-a-time for minimal resources or as a fully connected crossbar for higher parallelism and throughput. XAIF therefore inherits configurability from the host interconnect rather than defining a fixed fabric of its own.

The memory subsystem is likewise configurable in total size, addressing scheme, and number of banks. The paper also states that memory providers may support per-bank clock/power gating and retention. XAIF is designed to let accelerators “access shared memory resources efficiently,” but the paper does not describe a hardware coherency protocol. A cautious inference is that XAIF operates in a shared-memory embedded SoC context in which synchronization and memory visibility are managed explicitly by software and integration discipline rather than by a cache-coherent interconnect.

Peripheral support is split across a main domain and an always-on domain. The reported peripherals include PLIC, timers, GPIO, I2C, I2S, and SPI. The always-on domain includes the SoC controller, boot ROM, power manager, fast interrupt controller, DMA, and minimal communication peripherals. Since XAIF bundles interrupts and power-management control signals, these platform services are part of the environment within which XAIF-attached accelerators operate.

The implementation and exploration methodology further situates XAIF. X-HEEP supports FPGA prototyping, ASIC implementation, and mixed SystemC-RTL modeling. The cited infrastructure includes FuseSoC-managed flows, Verilator and commercial simulators, Synopsys Design Compiler for ASIC, and Vivado for FPGA. FPGA targets include Pynq-Z2, ZCU104, and Nexys A7. Linux-based deployment is supported through the FEMU environment, with X-HEEP in programmable logic and Linux on the processing-system side, controlled through a Python API. The paper does not indicate that XAIF changes conceptually across these flows; this suggests that flow-specific variation is implementation-level rather than a change in XAIF’s architectural role.

5. Quantitative characteristics and integrated case studies

The paper does not isolate XAIF with a standalone area, power, or latency number. There is no explicit “XAIF costs X gates” or “adds Y ns.” Quantitative assessment is therefore reported at the X-HEEP host-platform level and at the level of XAIF-enabled heterogeneous systems rather than as a microarchitectural benchmark of XAIF itself (Machetti et al., 23 Aug 2025).

At the host level, X-HEEP is reported as implemented in TSMC 65 nm, at 300 MHz and 0.8 V, with a total host area of 0.15 mm² and total leakage of 29 µW. With power-down support, minimum leakage is 3 µW. The reported area distribution is: memory banks 44%, always-on peripheral subsystem 21%, standard peripheral subsystem 11%, CV32E40P CPU 18%, bus 4%, and debug 2%. The leakage distribution is: memory banks 84% total, 42% each, AO peripheral subsystem 6%, standard peripheral subsystem 4%, CPU 5%, bus 2%, and debug 2%. The authors interpret these data as evidence that the host overhead needed to enable heterogeneous acceleration is low, while memory dominates both area and leakage.

The main demonstrator integrates NM-Carus with X-HEEP for seizure detection using an early-exit transformer and an early-exit CNN. The final models are reported as follows: for the transformer, early-exit weight 0.1, entropy threshold 0.45, 73% early-exit rate, and F1 from 0.6223 to 0.53; for the CNN, early-exit weight 0.01, threshold 0.35, 82% early-exit rate, and F1 from 0.57 to 0.49. In this integrated heterogeneous system, the reported gains are up to 7.3× speedup and 3.6× energy improvement over CPU-only execution.

The paper also reports broader system-level performance and energy results. For early-exit inference on the CPU alone, speedup reaches 1.6× for the transformer and 2.1× for the CNN, with up to 1.6× energy improvement. NM-Carus offload without early exit achieves up to 3.4× speedup for transformer and CNN, with up to 2.2× energy improvement. NM-Carus + early exit reaches up to 5.4× for the transformer and 7.3× for the CNN, with up to 3.6× energy improvement for the transformer and 3.4× for the CNN.

The accelerator case studies used to illustrate X-HEEP’s heterogeneous integration breadth are similarly varied. Among memory-like accelerators, the paper cites Blade with up to 4.8× energy savings, NM-Carus / NM-Caesar with up to 53.9× acceleration, ARCANE with up to 84× speedup, and HEEPstor with up to 4.5× speedup. Among master accelerators, it cites OpenEdge CGRA with up to 4.9× energy savings, STRELA with up to 18.6× speedup, e-GPU with up to 7× acceleration and 45% energy improvement and area overhead below 1.3×, and an Im2Col accelerator using the multi-channel DMA and 2D addressing for up to 6.1× acceleration. Among coprocessors, it reports Quadrilatero with up to 3.87× speedup and 15% energy savings, Coprosit with 38% area savings and 54% energy reduction versus standard IEEE-754 FP units, and ATHOS with 7.74× and 4.12× speedups and area overhead 1.47×.

These figures are not protocol-level measurements of XAIF. They are, rather, empirical demonstrations of what becomes feasible when a small configurable SoC exposes a native integration layer for accelerator classes with different attachment styles.

6. Specification boundaries, omissions, and broader relevance

The paper is explicit about XAIF’s architectural purpose but equally notable for what it does not specify. It does not provide a detailed XAIF signal list, a protocol timing diagram, a bus-width specification for XAIF paths, a register map, an exact software driver API for accelerator control, an explicit coherency model, a standalone area/power/latency cost of XAIF, or a formal wrapper specification for adding a new accelerator (Machetti et al., 23 Aug 2025).

For that reason, XAIF is best understood as an integration concept and host capability rather than a fully specified standalone bus protocol. The strongest textual description remains architectural: XAIF standardizes the connection of accelerators to X-HEEP’s OBI interconnect, shared memory system, DMA engine, interrupt infrastructure, and power manager. A plausible implication is that software control follows the pattern stated or implied by the surrounding architecture: CPU configuration through the slave path, accelerator execution using shared memory or DMA or master accesses, and completion or event signaling through interrupts.

A cautious inference from the host description is that XAIF operates in a shared-memory, non-coherent embedded SoC setting, since the paper mentions no caches in the baseline host description, no cache-coherent interconnect, and no coherence maintenance protocol for accelerator accesses. The same caution applies to clocking, reset, and synchronization. The paper does not describe a XAIF clock-domain crossing scheme, reset handshake, arbitration algorithm, transaction ordering rule, or exact backpressure semantics.

In a broader engineering sense, XAIF belongs to a larger family of extensibility-oriented interface ideas. A separate paper on Twinac—a “universal framework” for virtual accelerator controls in particle-accelerator facilities—states that, “read through the lens of an extensible accelerator control interface such as XAIF,” Twinac is not itself a finished standard interface specification, but an architectural proposal centered on modular architecture, component abstraction for standardization, separation of concerns, agnostic interfaces for control systems, shared formats, well-defined APIs, a plugin system, and open and documented interfaces (Miceli et al., 28 Jul 2025). That paper concerns a different problem domain, but it shows that XAIF’s emphasis on decoupling reusable accelerator logic from platform-specific integration details resonates with a wider design vocabulary of extensible systems.

Within X-HEEP itself, however, XAIF remains specific and concrete in purpose: it is the standard accelerator integration layer that allows one configurable ultra-low-power RISC-V host to accommodate memory-like accelerators, autonomous master accelerators, and ISA-extension coprocessors without repeated ad hoc SoC surgery.