X-HEEP: Ultra-Low-Power RISC-V Edge Host

• X-HEEP is an open-source, configurable RISC-V platform designed for ultra-low-power edge computing with support for TinyAI and heterogeneous accelerator integration.
• It features flexible configurability of cores, memory, bus, and peripherals, enabling tailored solutions for control-oriented and compute-intensive tasks.
• Its integration of XAIF and CORE-V-XIF provides versatile mechanisms for accelerator coupling and power management, validated through FPGA and ASIC prototyping flows.

Searching arXiv for recent X-HEEP papers and related case studies. X-HEEP is an open-source, configurable, and extendible RISC-V platform positioned as a host system for ultra-low-power edge computing, especially TinyAI and heterogeneous systems that combine a microcontroller-class CPU with specialized accelerators (Machetti et al., 23 Aug 2025, Machetti et al., 2024). Across the literature, it appears in two closely related formulations: as the “eXtendible Heterogeneous Energy-Efficient Platform” in the 2024 microcontroller-oriented description (Machetti et al., 2024), and as an “open-source, configurable, and extendible RISC-V platform for ultra-low-power edge applications (TinyAI)” in the 2025 platform paper (Machetti et al., 23 Aug 2025). Its defining characteristics are configurability of cores, memories, buses, and peripherals; standardized accelerator integration through XAIF; optional coprocessor coupling through CORE-V-XIF; and support for FPGA prototyping, ASIC implementation, and mixed modeling flows (Machetti et al., 23 Aug 2025, Machetti et al., 2024). Subsequent papers use X-HEEP as a concrete integration substrate for system-level testing, posit arithmetic coprocessors, neuromorphic control, and FPGA emulation, which collectively clarify both its intended role and its practical trade-offs (Terzano et al., 10 Apr 2025, Mallasén et al., 30 Jan 2025, Barocci et al., 12 May 2026, Machetti et al., 23 Aug 2025).

1. Definition and architectural scope

X-HEEP is a single-core RISC-V SoC framework rather than a fixed chip instance (Machetti et al., 23 Aug 2025). The platform is described as configurable through SystemVerilog parameters and templates, with explicit control over core type, memory organization, bus topology, peripheral composition, and accelerator interfaces (Machetti et al., 23 Aug 2025, Machetti et al., 2024). This places it between fixed low-power microcontrollers and heavier SoC generators: it aims to remain close to conventional RTL and ASIC/FPGA flows while still permitting systematic specialization for edge workloads (Machetti et al., 23 Aug 2025).

At the architectural level, X-HEEP consists of a configurable CORE-V CPU, on-chip memory, an OBI-based interconnect, peripheral domains, debug logic, a power manager, and extension hooks for accelerators and coprocessors (Machetti et al., 2024, Machetti et al., 23 Aug 2025). The 2025 platform paper expands the supported CPU set to CV32E20, CV32E40X, CV32E40P, and CV32E40PX (Machetti et al., 23 Aug 2025), whereas the 2024 paper lists CV32E20, CV32E40X, and CV32E40P (Machetti et al., 2024). This suggests that the platform evolved from a configurable MCU framework into a broader host substrate that also accommodates XIF-capable variants such as CV32E40PX.

A recurring architectural theme is that X-HEEP is meant to be the host, not usually the primary compute engine for expensive kernels. In the healthcare-oriented HEEPocrates system, the CPU handles control and orchestration while CGRA and IMC accelerators handle convolutional kernels (Machetti et al., 2024). In the TinyAI demonstrator with NM-Carus, X-HEEP again serves as the host that integrates CPU, memory, interrupt/control mechanisms, and accelerator interface logic (Machetti et al., 23 Aug 2025). In the neuromorphic ReckOn system, X-HEEP is “the main local controller,” while the AER decoder and ReckOn perform the timing-critical spike delivery and SNN execution (Barocci et al., 12 May 2026).

2. Configurability of compute, memory, bus, and peripherals

Configurability is a primary design objective. The papers explicitly identify core type, memory size, memory bank count, addressing scheme, bus topology, and peripheral selection as first-class parameters (Machetti et al., 23 Aug 2025, Machetti et al., 2024). X-HEEP is therefore not only extendible outward toward accelerators, but internally configurable in the host substrate itself.

Core options

The supported cores span lower-power control-oriented and higher-capability variants. The 2024 paper characterizes CV32E20 as optimized for control-oriented tasks, CV32E40P as processing-oriented, and CV32E40X as comparable in performance/power to CV32E40P but exposing CORE-V-XIF for custom coprocessors (Machetti et al., 2024). The 2025 paper adds CV32E40PX as another supported option and notes that CV32E40X and CV32E40PX support CORE-V-XIF (Machetti et al., 23 Aug 2025).

Memory system

Memory is banked SRAM with configuration of total size and number of banks (Machetti et al., 2024). The 2024 paper also distinguishes contiguous and interleaved addressing modes for fully connected interconnect configurations (Machetti et al., 2024). The stated trade-off is explicit: contiguous mode permits more selective low-power management of unused banks, whereas interleaved mode improves bandwidth for contiguous accesses but requires all banks to remain active (Machetti et al., 2024).

The 2025 static characterization emphasizes that memory dominates physical cost in a minimal X-HEEP host: two memory banks account for 44% of total area and 84% of total leakage, with each bank contributing 42% of leakage (Machetti et al., 23 Aug 2025). This supports the claim that platform overhead outside memory is relatively small.

Bus topology

Communication is based on OBI (Machetti et al., 23 Aug 2025, Machetti et al., 2024). Two main topologies are supported: a one-at-a-time configuration and a fully connected crossbar (Machetti et al., 23 Aug 2025). The 2024 paper gives more quantitative characterization: the one-at-a-time configuration is limited to 32 bit per bus cycle, and for the same slave/master count it occupies about 85% less silicon area than the fully connected version (Machetti et al., 2024). For a 16 × 16 matrix multiplication, the highest-performance configuration using CV32E40P + fully connected bus requires about 34% fewer clock cycles than CV32E40P + one-at-a-time bus (Machetti et al., 2024). These figures formalize the concurrency-versus-area trade-off that the later platform paper presents qualitatively (Machetti et al., 23 Aug 2025).

Peripheral domains

X-HEEP uses a split peripheral organization. The main peripheral domain includes common I/O and system peripherals such as PLIC, timers, GPIO, I2C, I2S, and SPI (Machetti et al., 23 Aug 2025); the 2024 paper lists a similar but slightly shorter set for the removable domain: PLIC, timer, GPIO, I2C, and SPI (Machetti et al., 2024). A distinct always-on domain contains blocks that must remain available for system control, including the SoC controller, boot ROM, power manager, fast interrupt controller, and DMA (Machetti et al., 23 Aug 2025, Machetti et al., 2024). The exact contents vary slightly across descriptions, but the architectural principle is consistent: aggressive power management requires an always-on control island and a gateable main peripheral domain.

3. XAIF and coprocessor integration

The most distinctive extension mechanism is XAIF, the eXtendible Accelerator InterFace, introduced as a configurable integration framework for accelerators with different programmability, bandwidth, interrupt, and power requirements (Machetti et al., 2024). The 2025 paper reframes it as a standardized bundle of interfaces and services that supports accelerators with varying area, power, and performance constraints (Machetti et al., 23 Aug 2025).

XAIF bundles configurable OBI slave and master connections, DMA extensions, interrupts, and power-management control signals (Machetti et al., 23 Aug 2025). In the 2024 description, it also includes a peripheral interface and a FIFO interface for DMA-friendly peripheral integration (Machetti et al., 2024). This makes XAIF broader than a simple memory-mapped register interface: it covers control-plane access, data-plane memory access, synchronization, and lifecycle management.

The literature presents at least three extension styles:

Integration style	Mechanism	Typical role
Memory-mapped accelerator	XAIF slave OBI	Configuration, status, private memories
Master-capable accelerator	XAIF master OBI	Direct access to shared memory
ISA coprocessor	CORE-V-XIF	Custom instructions and tightly coupled execution

The distinction between XAIF and XIF is important. XAIF addresses external or tightly coupled accelerators at the SoC level, while CORE-V-XIF supports coprocessors that extend the ISA when XIF-capable cores are used (Machetti et al., 23 Aug 2025, Machetti et al., 2024). This dual-path extensibility is central to X-HEEP’s positioning.

The posit-enabled PHEE system is the clearest XIF-based example. There, Coprosit is attached to the cv32e40px core through CV-X-IF, and X-HEEP is the “foundational hardware infrastructure” and integration framework (Mallasén et al., 30 Jan 2025). The point is not merely that X-HEEP can host an accelerator, but that it can host a tightly coupled arithmetic subsystem without invasive modifications to the CPU datapath. The paper explicitly states that X-HEEP “natively integrates CV-X-IF support with the cv32e40x and cv32e40px CPUs” (Mallasén et al., 30 Jan 2025).

By contrast, the 2026 ReckOn paper uses X-HEEP not through CORE-V-XIF or XAIF but primarily through the SPI peripheral and HAL, with the accelerator datapath mediated by dedicated logic such as the AER decoder (Barocci et al., 12 May 2026). This demonstrates that, in practice, X-HEEP can serve as a controller substrate even when the accelerator coupling is looser or implemented via peripheral-style interfaces rather than custom instruction paths.

4. Power management and ultra-low-power design

Power awareness is a central architectural theme in both the 2024 and 2025 X-HEEP papers (Machetti et al., 2024, Machetti et al., 23 Aug 2025). The platform supports clock-gating, power-gating, and retention, applied to CPU, peripherals, memory banks, and externally integrated accelerators via XAIF power-control hooks (Machetti et al., 2024). The always-on domain contains the power manager, which exposes software-visible control over these strategies (Machetti et al., 2024).

Banked memory is especially important for low-power behavior. The 2024 paper states that each SRAM bank supports a retention state that reduces leakage by about 42.5% compared to active leakage (Machetti et al., 2024). The 2025 host characterization shows how strongly memory dominates static power: the host’s total leakage is 29 µW, but minimum leakage with selective power management is 3 µW (Machetti et al., 23 Aug 2025). This suggests that X-HEEP’s configurability of bank count and bank-level control is not incidental but fundamental to its ULP operating model.

The HEEPocrates case study provides the most concrete low-power system data (Machetti et al., 2024). Fabricated in TSMC 65 nm low-power CMOS, it operates from 0.8 V to 1.2 V, reaching 170 MHz at 0.8 V and 470 MHz at 1.2 V (Machetti et al., 2024). Reported whole-chip power spans 270 µW at 32 kHz, 0.8 V to 48 mW at 470 MHz, 1.2 V (Machetti et al., 2024). During acquisition at 1 MHz, 0.8 V, the complete system consumes 384 µW; disabling unused memory banks, the peripheral domain, and external accelerators reduces this to 310 µW, and turning the CPU off during idle periods reduces it further to 286 µW (Machetti et al., 2024). These figures quantify the benefit of fine-grained domain control.

The 2025 X-HEEP platform paper reports a much smaller characterized host than HEEPocrates: 0.15 mm², 29 µW leakage, at TSMC 65 nm, 0.8 V, 300 MHz (Machetti et al., 23 Aug 2025). The apparent difference reflects different scopes: HEEPocrates is a healthcare-oriented instantiation with accelerators and broader system content (Machetti et al., 2024), whereas the 2025 paper characterizes a minimal host platform (Machetti et al., 23 Aug 2025). This suggests that “X-HEEP” denotes a configurable family of instantiations rather than a single fixed PPA point.

5. Implementation flows, prototyping, and software environment

A defining practical feature of X-HEEP is support for multiple development flows. The platform uses FuseSoC for simulation and synthesis workflows (Machetti et al., 23 Aug 2025, Machetti et al., 2024, Mallasén et al., 30 Jan 2025). Supported environments include open-source and commercial simulators, Verilator, Vivado for FPGA synthesis, and Synopsys Design Compiler for ASIC synthesis (Machetti et al., 23 Aug 2025, Machetti et al., 2024). The 2025 platform paper also states support for mixed SystemC-RTL modeling (Machetti et al., 23 Aug 2025).

Software support includes a HAL and FreeRTOS support (Machetti et al., 23 Aug 2025, Machetti et al., 2024). In practice, later papers use X-HEEP in several distinct software models. The TestIt system-integration paper drives X-HEEP through existing build, simulation, FPGA, and debug flows using Makefile targets such as sw-sim, sw-fpga, sim-build, sim-run, fpga-build, fpga-load, gdb-setup, and deb-setup (Terzano et al., 10 Apr 2025). There, X-HEEP applications are instrumented through generated C and header files, and result collection uses an application-emitted regular-expression channel rather than debugger memory reads (Terzano et al., 10 Apr 2025). The neuromorphic ReckOn paper uses bare-metal firmware on X-HEEP with the HAL to configure the SPI Host IP, with JTAG for deployment/debug and UART for monitoring (Barocci et al., 12 May 2026).

FPGA prototyping is explicitly supported in both standalone and SoC-assisted forms. The 2025 X-HEEP platform paper lists Pynq-Z2, ZCU104, and Nexys A7 as supported boards for standalone FPGA mode (Machetti et al., 23 Aug 2025). It also introduces a Linux-assisted mode called FEMU (FPGA EMUlation Platform), in which Linux runs on the FPGA processing system while X-HEEP runs in programmable logic (Machetti et al., 23 Aug 2025).

The dedicated FEMU paper elaborates this mode. In X-HEEP-FEMU, X-HEEP is instantiated in the reconfigurable hardware region on a Xilinx Zynq-7020/Pynq-Z2, while an ARM Cortex-A9 processing system runs Ubuntu, a Python environment, and a Jupyter Notebook interface (Machetti et al., 23 Aug 2025). The framework virtualizes debugger, ADC, flash, and accelerators, and combines RH performance counters with energy models derived from HEEPocrates silicon (Machetti et al., 23 Aug 2025). This makes X-HEEP not only a host RTL platform but also a host within a broader emulation methodology for TinyAI heterogeneous systems.

6. Representative instantiations and application domains

The literature uses X-HEEP across several distinct domains, and these uses collectively define its practical envelope.

HEEPocrates: healthcare-oriented accelerator host

In the 2024 paper, HEEPocrates is an X-HEEP instantiation for healthcare applications, built with CV32E20, 8 SRAM banks of 32 KiB each for 256 KiB total, contiguous addressing mode, a fully connected bus, all available peripherals, and integrated CGRA and IMC accelerators across 11 power domains (Machetti et al., 2024). For a 16 × 16 convolution with 3 × 3 filter, the integrated accelerators deliver 4.9× and 4.8× energy benefits for CGRA and IMC, respectively, relative to host CPU execution (Machetti et al., 2024).

TinyAI host with NM-Carus

The 2025 platform paper uses X-HEEP as the host for near-memory accelerators targeting early-exit dynamic networks (Machetti et al., 23 Aug 2025). In the reported heterogeneous system, combining early exit with NM-Carus yields up to 7.3× performance speedup and 3.6× energy improvement versus CPU-only execution (Machetti et al., 23 Aug 2025). The maximum speedup is reported for the CNN with early exit on the accelerator, while the maximum energy improvement is reported for the transformer in the combined setup (Machetti et al., 23 Aug 2025).

PHEE: posit-enabled X-HEEP

In PHEE, X-HEEP is the SoC framework into which the Coprosit posit coprocessor is integrated via CV-X-IF (Mallasén et al., 30 Jan 2025). The design uses the cv32e40px core, and the authors describe X-HEEP as an open-source configurable framework to generate RISC-V SoCs and streamline integration of tightly coupled low-power edge accelerators (Mallasén et al., 30 Jan 2025). The paper does not provide full-system X-HEEP/PHEE PPA, but it does report that the Coprosit subsystem is 38% smaller and consumes about 28% less power than the compared floating-point subsystem, while the underlying arithmetic unit achieves about 37% smaller area and 54% less power than the FP32 counterpart (Mallasén et al., 30 Jan 2025). A plausible implication is that X-HEEP’s value here lies less in its own standalone PPA and more in its ability to host application-specific arithmetic extensions cleanly.

ReckOn neuromorphic controller

In the 2026 ReckOn paper, X-HEEP is an “FPGA-synthesizable open source microcontroller” and “open-source microcontroller based on the RISC-V Instruction Set” used as a local controller for a recurrent SNN accelerator (Barocci et al., 12 May 2026). It configures ReckOn over SPI using the HAL, while BRAM-backed datasets and an FSM-based AER decoder handle spike scheduling and epoch accounting (Barocci et al., 12 May 2026). On a PYNQ-Z2 / XC7Z020, the X-HEEP-controlled architecture runs at 10 MHz and uses 45,651 LUTs, 145 DSPs, and 94 BRAM tiles before debug overhead; the table-reported version with debug reaches 48,483 LUTs, 26,125 FFs, 145 DSPs, and 99.5 BRAM (Barocci et al., 12 May 2026). The cue-accumulation benchmark reaches 92.4% average training accuracy and 96.8% average validation accuracy, with “no substantial differences in terms of accuracy” relative to RTL, ARM-managed FPGA, and taped-out silicon (Barocci et al., 12 May 2026).

System-level validation vehicle for TestIt

The TestIt paper uses X-HEEP as its principal full-system integration-testing case study (Terzano et al., 10 Apr 2025). X-HEEP is described there as an open-source 32-bit RISC-V MCU, extended with a tightly DMA-coupled im2col Smart Peripheral Controller (SPC) (Terzano et al., 10 Apr 2025). TestIt generates randomized datasets and golden references, embeds them into C/H files compiled into the X-HEEP software image, and runs the resulting self-checking application in simulation or on FPGA (Terzano et al., 10 Apr 2025). The case study exposes a hardware handshake bug and a software HAL overflow bug that unit-level or idealized verification may miss (Terzano et al., 10 Apr 2025). This use is significant because it portrays X-HEEP as a realistic HW/SW integration platform whose correctness depends on accelerator RTL, MCU hardware, DMA behavior, HAL code, test applications, and deployment environment.

7. Empirical trade-offs, limitations, and research significance

Several trade-offs recur across the papers. First, X-HEEP’s openness and configurability make it valuable as a reusable host platform, but memory and debug infrastructure often dominate practical resource costs. In the 2025 host characterization, memory dominates area and leakage (Machetti et al., 23 Aug 2025). In the ReckOn FPGA deployment, coexistence of X-HEEP, accelerator logic, dataset BRAMs, and debug logic leaves little room for further IP integration on XC7Z020 (Barocci et al., 12 May 2026).

Second, the platform’s flexibility does not imply that every paper exercises every extension mechanism. The neuromorphic controller work emphasizes SPI- and HAL-based control rather than XAIF or XIF (Barocci et al., 12 May 2026). The TestIt case study focuses on full-stack integration and DMA-mediated accelerator use, not on a generic signal-level exposition of XAIF (Terzano et al., 10 Apr 2025). The posit work centers on XIF-based CPU extension rather than memory-mapped accelerator integration (Mallasén et al., 30 Jan 2025). This suggests that X-HEEP’s practical significance lies in accommodating multiple accelerator attachment styles rather than prescribing one canonical method.

Third, some aspects remain under-specified at protocol or microarchitectural detail. The 2025 X-HEEP paper does not provide a deep signal-level XAIF specification (Machetti et al., 23 Aug 2025). The PHEE paper does not provide an explicit memory map or detailed CV-X-IF timing/interface specification (Mallasén et al., 30 Jan 2025). The ReckOn paper does not supply a detailed firmware structure, interrupt model, or timer-driven control path for X-HEEP (Barocci et al., 12 May 2026). The TestIt case study explicitly states that it does not provide a full block-level architectural breakdown, memory map, or detailed interface timing diagram for X-HEEP itself (Terzano et al., 10 Apr 2025). These omissions do not negate the platform’s documented functionality, but they indicate that the published literature emphasizes system integration and case studies more than exhaustive platform specification in a single source.

Fourth, X-HEEP occupies a specific position relative to other open-source systems. The 2024 paper distinguishes it from platforms such as PULPissimo, Cheshire, BlackParrot, OpenTitan, Chipyard, LiteX, and ESP on the basis of its combined focus on ultra-low-power microcontroller-class operation, configurability of core/bus/memory/peripherals, native accelerator interfaces, interrupt and power-control support for accelerators, and both FPGA and ASIC flow support (Machetti et al., 2024). The 2025 paper sharpens that position by tying X-HEEP directly to TinyAI host requirements and by quantifying a minimal host implementation at 0.15 mm² and 29 µW leakage (Machetti et al., 23 Aug 2025).

Finally, the cumulative literature suggests a coherent interpretation of X-HEEP as a host-centric open hardware research platform: compact enough for ULP exploration, structured enough for ASIC and FPGA realization, and extensible enough to host memory-mapped accelerators, DMA-coupled peripherals, and XIF-based coprocessors (Machetti et al., 23 Aug 2025, Machetti et al., 2024, Mallasén et al., 30 Jan 2025). Its broader significance lies not in a single benchmark number, but in enabling repeatable research across heterogeneous TinyAI, biomedical arithmetic specialization, neuromorphic control, full-system verification, and FPGA-based emulation (Terzano et al., 10 Apr 2025, Barocci et al., 12 May 2026, Machetti et al., 23 Aug 2025).