X-HEEP-FEMU: FPGA Emulation for TinyAI Systems

• X-HEEP-FEMU is a supervised FPGA emulation environment that integrates hardware prototyping and energy-aware design for rapid evaluation of TinyAI systems.
• It partitions resources into a reconfigurable hardware region on the Zynq-7020 and a Linux-based ARM Cortex-A9 control region, enabling software virtualization, debugging, and performance monitoring.
• Empirical results demonstrate up to 9× acceleration for compute kernels and a 250× speed-up in flash virtualization, underscoring its effectiveness in heterogeneous system validation.

X-HEEP FPGA EMUlation (X-HEEP-FEMU) is the concrete instantiation of the FEMU framework for prototyping and evaluating TinyAI heterogeneous systems on SoC-based FPGAs. It places the X-HEEP host in the reconfigurable hardware region of a Xilinx Zynq-7020, runs a Linux-based Python environment on the ARM Cortex-A9 control side, and couples FPGA-resident execution with energy models derived from the HEEPocrates silicon implementation of X-HEEP in TSMC 65 nm CMOS (Machetti et al., 23 Aug 2025). In the broader X-HEEP lineage, FEMU is the Linux-based FPGA deployment mode identified in the X-HEEP platform work, alongside standalone FPGA support and an implementation flow based on FuseSoC and Vivado (Machetti et al., 23 Aug 2025).

1. Origins and platform context

X-HEEP is an open-source, configurable, and extendible RISC-V platform for ultra-low-power edge applications, especially TinyAI workloads. Its architectural intent is broader than FPGA deployment alone: the platform supports FPGA prototyping, ASIC implementation, and mixed SystemC-RTL modeling, while exposing configuration knobs for cores, memory, bus organization, and peripherals (Machetti et al., 23 Aug 2025). Earlier X-HEEP work positioned FPGA implementation as a first-class stage in a multi-target exploration flow, and the HEEPocrates demonstrator was implemented on Xilinx Zynq-7020, Zynq UltraScale+, and Artix 7 for early prototyping, verification, and system exploration before silicon validation in TSMC 65 nm low-power CMOS (Machetti et al., 2024).

Within that trajectory, FEMU generalizes FPGA deployment into a supervised emulation environment. The FEMU paper defines a reusable architecture in which the under-development heterogeneous system resides in a reconfigurable hardware region, while an OS-capable control software region provides supervision, communication, virtualization, performance monitoring, and energy estimation. X-HEEP-FEMU is the corresponding realization for X-HEEP, and the framework is described as open source and configurable, with repositories named x-heep-femu and x-heep-femu-sdk (Machetti et al., 23 Aug 2025).

This positioning matters because X-HEEP-FEMU is not merely an FPGA bitstream for X-HEEP. It is a host-controlled emulation environment intended to bridge early accelerator modeling, software bring-up, RTL integration, and energy-aware design-space exploration. The X-HEEP platform paper states that the Linux-based FEMU mode “significantly accelerates development workflows” by allowing developers to test and interact with hardware modules through high-level software without requiring low-level FPGA reprogramming or hardware description knowledge (Machetti et al., 23 Aug 2025).

2. Architectural organization of FEMU and X-HEEP-FEMU

FEMU is organized into two main regions: the Reconfigurable Hardware region (RH), where the under-development heterogeneous system is implemented, and the Control Software region (CS), where supervision and virtualization run under a standard operating system. In X-HEEP-FEMU, RH corresponds to the programmable logic of the Zynq-7020, while CS corresponds to the processing system based on ARM Cortex-A9 running Ubuntu Linux (Machetti et al., 23 Aug 2025).

Region	X-HEEP-FEMU contents
RH / PL	X-HEEP host, SPI-to-AXI bridge(s), OBI-AXI bridge, hardware FIFO, performance counters, optional RTL accelerators such as the CGRA
CS / PS	Ubuntu Linux, Python runtime, Jupyter interface, OpenOCD server, GDB client, software FIFO, energy estimation software, accelerator software models

The RH contains the timing-relevant hardware prototype. In the X-HEEP-FEMU specialization, this includes X-HEEP itself, support logic for virtualization and monitoring, and RTL accelerators when available. The paper explicitly lists SPI-to-AXI bridges for ADC and flash virtualization, an OBI-AXI bridge for accelerator virtualization through DRAM-based communication, a hardware FIFO for ADC virtualization, and performance counters that monitor X-HEEP domains and power-state residency (Machetti et al., 23 Aug 2025).

The CS contains the high-level supervisory environment. X-HEEP-FEMU places a Linux-based Python environment on the ARM Cortex-A9, together with user interaction, Jupyter-based access, OpenOCD/GDB-based debug infrastructure, software-side peripheral and accelerator virtualization, and energy-estimation logic (Machetti et al., 23 Aug 2025). A Python class abstracts the platform and is integrated with Jupyter Notebooks, so interaction can occur through a web browser.

This RH/CS split is central to the framework’s method. Real-time and implementation-sensitive behavior stays in RH, whereas components that benefit from flexibility, rapid iteration, or software modeling are moved into CS. The paper presents this as the enabling mechanism for gradual migration from software models to RTL accelerators and for combining hardware execution with software-controlled observability and estimation (Machetti et al., 23 Aug 2025).

3. X-HEEP substrate and heterogeneous integration model

X-HEEP-FEMU inherits the configurability of X-HEEP itself. The X-HEEP platform supports multiple OpenHW Group CORE-V cores—CV32E20, CV32E40X, CV32E40P, and CV32E40PX—together with a configurable memory subsystem, configurable bus topology, and selectable peripherals (Machetti et al., 23 Aug 2025). Communication uses the Open Bus Interface (OBI), and the bus can range from a one-at-a-time configuration to a fully connected crossbar. Memory is configurable in total size, addressing scheme, and number of banks, and each bank can be clock-gated, power-gated, or placed in retentive mode if supported by the memory provider (Machetti et al., 23 Aug 2025).

Accelerator integration is standardized through the eXtendible Accelerator InterFace (XAIF). XAIF bundles configurable OBI slave connections, configurable OBI master connections, DMA extensions, interrupts, and power-management control signals; when paired with CV32E40X or CV32E40PX, it also supports CORE-V-XIF for co-processors implementing custom ISA extensions (Machetti et al., 23 Aug 2025). This makes X-HEEP-FEMU structurally suitable for several accelerator styles: slave-style register-controlled blocks, master-capable accelerators with shared-memory access, DMA-assisted accelerators, interrupt-capable offload engines, and co-processors attached through XIF.

The X-HEEP-FEMU paper describes a staged development model that maps directly onto this interface structure. In the early stage, an accelerator can be represented as a software model in CS. In the later stage, the accelerator is transformed into RTL and integrated into RH. Operationally, the framework distinguishes CPU-only mode, offloaded mode with a virtualized accelerator, and offloaded mode with an RTL accelerator (Machetti et al., 23 Aug 2025). In the virtualized mode, X-HEEP writes configuration parameters and input data into predefined DRAM regions through the OBI-AXI bridge, PS-side software processes them, and results are written back into the same shared memory space. In the RTL mode, the accelerator executes directly in PL and is monitored by the same counter and energy-estimation infrastructure.

This arrangement gives X-HEEP-FEMU a dual role. At one level it is an FPGA realization of a configurable RISC-V host. At another it is a heterogeneous prototyping environment in which the host/accelerator contract remains stable while the implementation of the accelerator migrates from software model to RTL. That continuity is one of the main reasons X-HEEP-FEMU is useful for TinyAI hardware/software co-design (Machetti et al., 23 Aug 2025).

4. Virtualization, control paths, and instrumentation

X-HEEP-FEMU virtualizes several peripherals and services through explicit bridges between RH and CS. Debugger virtualization is implemented by connecting the X-HEEP JTAG interface to PS GPIO, with OpenOCD acting as server and GDB as client. The X-HEEP UART is routed to a UART port exposed by the PS and is used for application-level logging and debugging (Machetti et al., 23 Aug 2025). This gives the Linux control side direct access to bring-up and debug channels without requiring a separate external board-level debug stack.

ADC virtualization uses an SPI-to-AXI bridge together with a hardware FIFO. The software side moves samples from SD card storage into PS DRAM through a software FIFO, and the hardware FIFO then exposes that data to X-HEEP over the virtualized ADC path. Flash virtualization uses a second SPI-to-AXI bridge connected to an AXI slave port exposed by the PS, so X-HEEP can access storage semantics through a PS-managed backing store rather than a physical flash device (Machetti et al., 23 Aug 2025).

Accelerator virtualization follows a shared-memory model. The OBI-AXI bridge allows X-HEEP to access predefined DRAM regions, PS-side software models detect configuration and input data placed there by X-HEEP, compute the corresponding outputs, and write results back into the same memory space (Machetti et al., 23 Aug 2025). This is not presented as a generic RPC system; it is a memory-mediated interaction model in which the accelerator contract remains software-visible to the X-HEEP host.

Instrumentation is built into the RH. Performance counters track how long X-HEEP domains spend in four states—active, clock-gated, power-gated, and retention—and the CS reads these counters after execution to compute energy estimates (Machetti et al., 23 Aug 2025). The platform therefore observes both execution progress and power-state residency rather than relying exclusively on coarse end-of-run timing. The X-HEEP platform paper adds that the Linux-based FEMU environment is intended to accelerate interaction with hardware modules through high-level software; this suggests that virtualization and instrumentation are not auxiliary features but core parts of the development model (Machetti et al., 23 Aug 2025).

5. Validation workflows and empirical behavior

The X-HEEP-FEMU evaluation is organized around three case studies: signal acquisition characterization, computation of typical TinyAI workloads, and sample collection and storage. For signal acquisition, X-HEEP executes a kernel that acquires a 5 s window of pre-sampled data over a virtualized SPI-based path at six sampling frequencies from 100 Hz to 100 kHz. At low sampling frequencies, both X-HEEP-FEMU and the HEEPocrates silicon baseline spend the overwhelming majority of time in sleep mode, with active periods contributing less than 1% of total acquisition time and energy; at high sampling frequencies, the active phase accounts for more than 70% of total acquisition time and energy (Machetti et al., 23 Aug 2025).

For compute kernels, the paper evaluates matrix multiplication, 2D convolution, and a 512-point FFT in CPU-only and CGRA-accelerated configurations. The reported result is that CGRA acceleration reduces processing time by up to $9\times$, with CONV showing the largest performance gain, and also consistently reduces energy consumption. CPU-only X-HEEP-FEMU energy trends align well with HEEPocrates, with average deviation about 5%, whereas CGRA-accelerated deviation rises to about 20% because accelerator power is estimated from post-place-and-route analysis rather than silicon measurements (Machetti et al., 23 Aug 2025).

The storage case study highlights the effect of flash virtualization. A wood-moisture classification use case acquires 35,000 samples of 16 bits each, corresponding to more than 70 KiB per acquisition window. With flash virtualization, one window is transferred in about 10 ms, whereas physical SPI flash requires 2.5 s; for 240 windows, X-HEEP-FEMU completes the transfer in 2.4 s instead of 10 min, corresponding to a reported $250\times$ speed-up (Machetti et al., 23 Aug 2025).

A complementary validation methodology appears in the X-HEEP-based TestIt study. TestIt is an open-source Python package for software-based self-test of complete hardware/software systems, demonstrated on an X-HEEP MCU extended with a Smart Peripheral Controller accelerator and executed in both RTL simulation and FPGA mode on a PYNQ-Z2 board. In a 300-iteration performance characterization campaign, the FPGA run took around 0:31 hours versus 6:07 hours for a Verilator-based campaign, yielding an $11\times$ speed-up, while also detecting a protocol bug in the SPC controller and a software bug in the DMA HAL function get_increment_b_1D() (Terzano et al., 10 Apr 2025). This suggests that X-HEEP-FEMU is especially compatible with firmware-embedded, self-reporting validation flows in which the application emits pass/fail and performance data directly, reducing dependence on intrusive FPGA observability.

6. Related FPGA deployment patterns, limits, and scaling directions

The published X-HEEP-FEMU description is detailed at the architectural level but intentionally incomplete as a low-level implementation manual. The FEMU paper does not provide a full memory map, full address-space table, exact bus widths, exact driver architecture, formal synchronization protocol details, or a dedicated FPGA clock/reset implementation description (Machetti et al., 23 Aug 2025). The X-HEEP platform paper likewise confirms FPGA support and names FEMU, but does not report FPGA-specific quantitative results such as LUT, FF, BRAM, DSP counts, FPGA timing, or PS-PL bandwidth (Machetti et al., 23 Aug 2025). These omissions define the boundary between the framework’s architectural documentation and the engineering detail required for full reproduction.

A related FPGA integration pattern is shown by the ReckOn neuromorphic accelerator study. There, X-HEEP is synthesized as a soft microcontroller in FPGA fabric and acts as the controlling unit for an ASIC-origin accelerator through SPI, while JTAG and UART connect X-HEEP to the host PC and dedicated RTL glue logic handles timing-sensitive event delivery. On a PYNQ-Z2, the X-HEEP-controlled architecture ran at 10 MHz and the ARM-controlled architecture at 15 MHz, illustrating a clear division between software control plane and hardware datapath (Barocci et al., 12 May 2026). This does not define X-HEEP-FEMU itself, but it shows a closely related deployment style in which X-HEEP serves as the embedded host inside an FPGA-resident heterogeneous prototype.

A broader scalability question concerns whether X-HEEP-FEMU remains a single-FPGA environment or evolves toward distributed emulation. The published FEMU work is a Zynq-7020-based, single-device platform. If future X-HEEP variants grow toward larger memory systems, accelerator-rich subsystems, or multi-core organizations, EMiX offers a relevant architectural template: partition a monolithic RISC-V design at natural subsystem boundaries, transport cross-partition traffic over a common AXI-Stream layer, and combine low-latency direct links with scalable switched communication without fundamental RTL redesign (Kropotov et al., 29 Apr 2026). This is a plausible extension rather than a present property of X-HEEP-FEMU, because EMiX is based on OpenPiton NoC boundaries and would require new bridges for X-HEEP-native interfaces such as OBI, AXI, AXI-Lite, APB, or DMA traffic.

Taken together, the available literature presents X-HEEP-FEMU as a supervised, instrumented FPGA emulation environment centered on X-HEEP, Linux-side virtualization, and silicon-grounded energy estimation. Its distinctive contribution is the combination of accelerator virtualization, RTL migration, debugger and storage virtualization, domain-level performance monitoring, and system-level energy estimation in a single workflow (Machetti et al., 23 Aug 2025). Its most important practical limitation is that several low-level deployment details remain outside the published papers and must be recovered from repositories or supplementary implementation artifacts.