---
title: 'X-HEEP: Ultra-Low-Power RISC-V Edge Host'
url: https://www.emergentmind.com/topics/x-heep
type: topic
---

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

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 [2508.16959][2401.05548]. Across the literature, it appears in two closely related formulations: as the “eXtendible Heterogeneous Energy-Efficient Platform” in the 2024 microcontroller-oriented description [2401.05548], and as an “open-source, configurable, and extendible RISC-V platform for ultra-low-power edge applications (TinyAI)” in the 2025 platform paper [2508.16959]. 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 [2508.16959][2401.05548]. 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 [2504.07555][2501.18253][2605.12217][2508.16981].

## 1. Definition and architectural scope

X-HEEP is a single-core RISC-V SoC framework rather than a fixed chip instance [2508.16959]. 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 [2508.16959][2401.05548]. 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 [2508.16959].

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 [2401.05548][2508.16959]. The 2025 platform paper expands the supported CPU set to **CV32E20**, **CV32E40X**, **CV32E40P**, and **CV32E40PX** [2508.16959], whereas the 2024 paper lists **CV32E20**, **CV32E40X**, and **CV32E40P** [2401.05548]. 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 [2401.05548]. 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 [2508.16959]. 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 [2605.12217].

## 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 [2508.16959][2401.05548]. 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 [2401.05548]. The 2025 paper adds **CV32E40PX** as another supported option and notes that **CV32E40X** and **CV32E40PX** support **CORE-V-XIF** [2508.16959].

### Memory system

Memory is banked SRAM with configuration of total size and number of banks [2401.05548]. The 2024 paper also distinguishes **contiguous** and **interleaved** addressing modes for fully connected interconnect configurations [2401.05548]. 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 [2401.05548].

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 [2508.16959]. This supports the claim that platform overhead outside memory is relatively small.

### Bus topology

Communication is based on **OBI** [2508.16959][2401.05548]. Two main topologies are supported: a **one-at-a-time configuration** and a **fully connected crossbar** [2508.16959]. 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 [2401.05548]. 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** [2401.05548]. These figures formalize the concurrency-versus-area trade-off that the later platform paper presents qualitatively [2508.16959].

### 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** [2508.16959]; the 2024 paper lists a similar but slightly shorter set for the removable domain: **PLIC**, **timer**, **GPIO**, **I2C**, and **SPI** [2401.05548]. 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** [2508.16959][2401.05548]. 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 [2401.05548]. The 2025 paper reframes it as a standardized bundle of interfaces and services that supports accelerators with varying area, power, and performance constraints [2508.16959].

XAIF bundles **configurable OBI slave and master connections**, **DMA extensions**, **interrupts**, and **power-management control signals** [2508.16959]. In the 2024 description, it also includes a **peripheral interface** and a **FIFO interface** for DMA-friendly peripheral integration [2401.05548]. 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 [2508.16959][2401.05548]. 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 [2501.18253]. 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” [2501.18253].

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 [2605.12217]. 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 [2401.05548][2508.16959]. The platform supports **clock-gating**, **power-gating**, and **retention**, applied to CPU, peripherals, memory banks, and externally integrated accelerators via XAIF power-control hooks [2401.05548]. The always-on domain contains the **power manager**, which exposes software-visible control over these strategies [2401.05548].

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** [2401.05548]. 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** [2508.16959]. 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 [2401.05548]. 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** [2401.05548]. Reported whole-chip power spans **270 µW** at **32 kHz**, **0.8 V** to **48 mW** at **470 MHz**, **1.2 V** [2401.05548]. 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** [2401.05548]. 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** [2508.16959]. The apparent difference reflects different scopes: HEEPocrates is a healthcare-oriented instantiation with accelerators and broader system content [2401.05548], whereas the 2025 paper characterizes a minimal host platform [2508.16959]. 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 [2508.16959][2401.05548][2501.18253]. Supported environments include open-source and commercial simulators, **Verilator**, **Vivado** for FPGA synthesis, and **Synopsys Design Compiler** for ASIC synthesis [2508.16959][2401.05548]. The 2025 platform paper also states support for **mixed SystemC-RTL modeling** [2508.16959].

Software support includes a **HAL** and **FreeRTOS support** [2508.16959][2401.05548]. 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` [2504.07555]. 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 [2504.07555]. 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 [2605.12217].

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 [2508.16959]. 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 [2508.16959].

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 [2508.16981]. The framework virtualizes debugger, ADC, flash, and accelerators, and combines RH performance counters with energy models derived from **HEEPocrates** silicon [2508.16981]. 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** [2401.05548]. 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 [2401.05548].

### TinyAI host with NM-Carus

The 2025 platform paper uses X-HEEP as the host for **near-memory accelerators** targeting early-exit dynamic networks [2508.16959]. 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 [2508.16959]. 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 [2508.16959].

### 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** [2501.18253]. 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 [2501.18253]. 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 [2501.18253]. 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 [2605.12217]. It configures ReckOn over **SPI** using the HAL, while BRAM-backed datasets and an **FSM-based AER decoder** handle spike scheduling and epoch accounting [2605.12217]. 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** [2605.12217]. 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 [2605.12217].

### System-level validation vehicle for TestIt

The TestIt paper uses X-HEEP as its principal full-system integration-testing case study [2504.07555]. 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)** [2504.07555]. 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 [2504.07555]. The case study exposes a hardware handshake bug and a software HAL overflow bug that unit-level or idealized verification may miss [2504.07555]. 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 [2508.16959]. 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 [2605.12217].

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 [2605.12217]. The TestIt case study focuses on full-stack integration and DMA-mediated accelerator use, not on a generic signal-level exposition of XAIF [2504.07555]. The posit work centers on XIF-based CPU extension rather than memory-mapped accelerator integration [2501.18253]. 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 [2508.16959]. The PHEE paper does not provide an explicit memory map or detailed CV-X-IF timing/interface specification [2501.18253]. The ReckOn paper does not supply a detailed firmware structure, interrupt model, or timer-driven control path for X-HEEP [2605.12217]. 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 [2504.07555]. 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 [2401.05548]. 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** [2508.16959].

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 [2508.16959][2401.05548][2501.18253]. 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 [2504.07555][2605.12217][2508.16981].

Source: https://www.emergentmind.com/topics/x-heep