---
title: FPGA EMUlation (FEMU) Research Overview
url: https://www.emergentmind.com/topics/fpga-emulation-femu
type: topic
---

# FPGA EMUlation (FEMU) Research Overview

Searching arXiv for recent and foundational FEMU-related papers to ground the article.
Search query: FEMU FPGA emulation open-source configurable emulation framework FPGA EMUlation
FPGA EMUlation (FEMU) denotes a class of FPGA-based emulation methodologies in which a device under test, an architectural model, or a physically motivated system model is realized in reconfigurable hardware so that validation can proceed at far higher effective speed than software simulation while preserving hardware-visible interfaces and, in many cases, cycle-accurate or cycle-approximate behavior. In the literature, the term appears both as a generic label for FPGA-based emulation and as the proper name of specific frameworks; recent work spans multi-FPGA full-system RISC-V emulation, TinyAI heterogeneous-system prototyping, mixed-signal analog emulation, quantum emulation, memory-system emulation, wireless channel emulation, and detector-readout emulation [2604.27012] [2508.16981].

## 1. Scope and usage of the term

In pre-silicon digital design, FPGA-level emulation is presented as a key step in chip design validation. EMiX, for example, targets full-system emulation of large many-core RISC-V systems whose monolithic RTL no longer fits on one board, and frames the problem explicitly as going beyond the resource limits of a single FPGA [2604.27012]. In contrast, the open-source and configurable FEMU framework for TinyAI heterogeneous systems uses an SoC-FPGA to combine an under-development hardware subsystem in a reconfigurable hardware region with a standard operating-system environment in a control software region [2508.16981].

Published work shows that FEMU is not confined to processor or SoC validation. The same basic idea is used for digitally driven mixed-signal systems, where analog dynamics are emulated by superposing precomputed step responses and evaluating outputs only when sampled by digital logic [2002.02072]; for motor-control hardware-in-the-loop, where a direct-current machine model is synthesized into an FPGA core through an HLS flow [1312.5704]; for multiplier-level fault injection in CNN accelerators [2501.12818]; for quantum algorithm emulation on low-tier FPGAs [2411.09320]; for neuromorphic architectures [2004.06061]; for NoC prototyping [2206.11613]; for scan-chain co-emulation over SCE-MI [1409.3276]; for non-volatile and hybrid memory studies [2202.07948] [2011.04567] [2309.06565]; and for wireless and RF scenario emulation [2208.03993] [2406.08714]. This suggests that FEMU is best understood as a methodology family rather than a single canonical architecture.

## 2. Recurrent architectural patterns

A recurring FEMU organization is a split between timing-critical FPGA logic and software-visible orchestration. In X-HEEP-FEMU, the reconfigurable hardware region contains the host subsystem, SPI-AXI and OBI-AXI bridge logic, virtualization modules, and memory-mapped performance counters, while the control software region is the Zynq Processing System running Linux, device drivers, a Python SDK, and a Jupyter interface [2508.16981]. EmuNoC adopts a similar decomposition: the software domain on the ARM cores generates traffic and tracks dependencies, the programmable-logic transactor performs clock halting and packet injection/ejection, and the NoC RTL itself is directly mapped to the FPGA fabric [2206.11613].

Another common pattern is the explicit use of transactors and virtualization shims. In SCE-MI-based scan-chain co-emulation, a SystemC testbench communicates with synthesizable message ports and a hardware FSM transactor that serializes scan operations on the FPGA [1409.3276]. In EMiX, NoC packets are wrapped into Aurora frames or Ethernet frames by dedicated NoC–Aurora and NoC–CMAC bridges [2604.27012]. In X-HEEP-FEMU, virtualization modules include debugger logic, ADC-FIFO, flash-FIFO, and accelerator-FIFO engines [2508.16981]. These designs replace direct software interaction with protocol-specific hardware mediators, thereby reducing communication granularity and keeping the fast path in reconfigurable logic.

A third recurring element is hardware-resident monitoring. X-HEEP-FEMU exposes cycle-count counters memory-mapped into the Processing System for performance and energy estimation [2508.16981]. METICULOUS distributes CSR-controlled latency, bandwidth, and error-rate parameters across emulated memory banks [2309.06565]. NORM includes an Energy Approximation block and an energy calculator that observe memory accesses and estimate Joule consumption from per-cycle constants [2202.07948]. Across these systems, observability is built into the emulator rather than being delegated entirely to external instrumentation.

## 3. Partitioning, interconnects, and scaling beyond one FPGA

When the DUT exceeds the capacity of one device, FEMU shifts from monolithic mapping to explicit partitioning. EMiX starts from a tiled NoC-based multi-core RTL and slices it along tile boundaries so that each FPGA hosts an integral number of tiles. With
$$
C=\lceil N_{\text{total}}/N_{\text{FPGA}}\rceil,
$$
the estimated per-FPGA resource fraction is written as
$$
\text{resource\_fraction}=\frac{C\times R_{\text{core}}}{R_{\text{FPGA capacity}}}.
$$
In the reported 64-core, 8-FPGA prototype, \(C=8\), with measured pre-interconnect fractions of \( \mathrm{LUT\_frac}\approx 0.55\), \( \mathrm{BRAM\_frac}\approx 0.48\), and \( \mathrm{DSP\_frac}\approx 0.50\); NoC-Aurora, NoC-CMAC, and CDC logic add approximately \(16\%\) more LUTs, yielding approximately \(71\%\) LUT utilization [2604.27012].

EMiX couples that partitioning strategy to a two-level interconnect. Level 1 is a low-latency point-to-point Aurora-64b/66b channel over QSFP-1; Level 2 is a scalable cross-connect through a 100 Gbps Ethernet switch via AMD CMAC on QSFP-0. Using \(B_{\text{link}}=W\times f\), the paper reports \(B_{\text{Aurora}}\approx 19.2\ \mathrm{GB/s}\) and \(B_{\text{CMAC}}\approx 20\ \mathrm{GB/s}\). For a NoC packet crossing \(h\) Aurora hops, \(L_{\text{msg}}=h\times \delta + L_{\text{bridge}}\), with \(\delta\approx 15\ \mathrm{ns}\) and \(L_{\text{bridge}}\approx 50\ \mathrm{ns}\); in the worst case for an 8-FPGA chain, \(L_{\text{msg}}\approx 155\ \mathrm{ns}\) [2604.27012]. The prototype boots Linux on 64 cores distributed over eight Alveo U55c boards at 50 MHz, reports sustained bare-metal throughput of \(1.2\times 10^7\) instructions/s per core and aggregate \(7.7\times 10^8\) IPS, and reports a speedup \(S(8)\approx 7.2\times\) over single-FPGA emulation [2604.27012].

Large-scale cluster-based scaling appears in Makinote, which aggregates 96 AMD/Xilinx Alveo U55c cards and targets RTL designs up to 750M ASIC cells. Its FPGA shell auto-connects user RTL to PCIe Gen4, DRAM, HBM, Ethernet, Aurora, UART, and JTAG, and HPC Challenge experiments on 32 FPGAs show that performance improves by 8 times over the single-FPGA case [2401.17984]. At the single-device end of the scaling spectrum, EmuNoC increases area efficiency sufficiently to model up to a 169-router NoC on one FPGA and reports a 36.3x to 79.3x speedup over the cited directly mapped hybrid-emulation baselines [2206.11613]. A plausible implication is that FEMU scaling proceeds along two orthogonal axes: distributing one design across many FPGAs, and maximizing area efficiency so that more of the design remains on one FPGA.

## 4. Fidelity mechanisms: time, latency, errors, and energy

FEMU systems differ substantially in what they preserve exactly. In mixed-signal emulation, the analog-dynamics architecture of Lim and colleagues is explicitly event driven: the Time Manager advances directly from one digital edge to the next, analog outputs are recomputed only at those instants, and no oversampling of the analog model is required. The authors state that accuracy is exact for any \(\Delta t_i\), with error limited only by lookup-table quantization, fixed-point arithmetic, or finite-depth truncation; the implementation achieves \(1\%\) accuracy and runs 3 orders of magnitude faster than a comparable high-performance CPU simulation [2002.02072].

In real-time control emulation, the direct-current machine emulator derived by Ahmed Ben Achballah and colleagues uses a 2nd-order Runge–Kutta discretization with
$$
V_h(k)=(2\alpha(k)-1)V_{in},
$$
$$
I_m(k+1)=aI_m(k)+\beta \Omega_m(k)+\gamma V_h(k),
$$
$$
\Omega_m(k+1)=\lambda I_m(k)+\mu \Omega_m(k)+\nu \operatorname{sign}[\Omega_m(k)].
$$
At a 100 MHz global clock, the raw floating-point core measures approximately \(350\ \mathrm{ns}\) per iteration, and current and speed curves from PC-based and FPGA-based runs overlay with less than \(0.1\%\) discrepancy [1312.5704]. Here the fidelity target is plant-model timing and numerical behavior under real-time deadlines rather than full-system software visibility.

Memory-oriented FEMU platforms make latency and fault semantics explicit configuration knobs. METICULOUS models an emulated memory-bank access as
$$
T_{\mathrm{emu}}=T_{\mathrm{DRAM}}+\ell,
$$
and reports that observed latency was exactly proportional to inserted latency, with a minimum overhead of approximately \(240\ \mathrm{ns}\) and a throughput ceiling of approximately \(450\ \mathrm{MB/s}\) per board [2309.06565]. NORM emulates FeRAM timing by mapping memory state into BRAM while shielding it from power-fail resets, using
$$
E_{\text{total}}=\sum \text{cycles}_i\times E_{\text{per\_cycle},i},
$$
and at 100 MHz models a 55 ns FeRAM access as 6 cycles, giving a 60 ns emulated latency [2202.07948]. In X-HEEP-FEMU, energy is derived from per-domain, per-state calibrated powers via
$$
E_{\text{total}}=\sum_d\sum_s P_{d,s}\cdot T_{d,s},
$$
with \(T_{d,s}=\text{cycles}_{d,s}/f_{\text{PL}}\); reported average deviation is \(5\%\) in CPU mode and \(20\%\) in CGRA mode [2508.16981]. These systems show that FEMU fidelity may target temporal behavior, energy behavior, persistence behavior, or all three concurrently.

## 5. Domain-specific realizations

The diversity of published FEMU systems is most evident in their domain-specific targets and validation criteria.

| Domain | Representative system | Reported result |
|---|---|---|
| Mixed-signal dynamics | Analog Dynamics Engine + Time Manager | \(1\%\) accuracy; 3 orders of magnitude faster than a comparable high-performance CPU simulation |
| Quantum emulation | AMARETTO | Successful emulation of sixteen qubits on a AMD Kria KV260 SoM |
| CNN fault injection | NVDLA-based FPGA emulation platform | Approximately \(37\times\) higher end-to-end throughput than software |
| Neuromorphic computing | TrueNorth reference design on Zynq UltraScale+ MPSoC | \(96.28\%\) MNIST accuracy; 10 000 test images in 10 s |
| Detector readout | ETROC emulator board | Bit error rate \(<10^{-14}\) over two weeks |
| Wireless channel emulation | CaST on Colosseum | \(\le 20\ \mathrm{ns}\) tap-delay accuracy; \(0.5\ \mathrm{dB}\) tap-gain accuracy |

These results are reported in [2002.02072] [2411.09320] [2501.12818] [2004.06061] [2302.01548] [2208.03993].

Within quantum-focused FEMU alone, the objectives differ. AMARETTO emphasizes a RISC-like pipeline, sparse gate handling, and all-on-chip state storage, and validates sixteen qubits on a low-tier KV260 platform [2411.09320]. AEQUAM adds an OpenQASM 2.0 compiler, Cython software models for number representation, and a VHDL generator parameterized by qubit count and parallelization level; synthesized on a Cyclone 10LP with a 20-bit fixed-point representation, it supports up to six qubits on that device and is validated with the mqt bench framework [2506.01029]. The contrast indicates that “quantum FEMU” can mean either maximizing qubit capacity on low-tier FPGAs or building a compiler-to-RTL toolchain that exposes systematic area/latency trade-offs.

Other domain-specific systems target infrastructure rather than algorithms. The CMS ETL readout-chip emulator reproduces command decoding, circular buffers, switching network, framing, CRC, and serializer/deserializer functions for four ETROC2 chips plus DAQ-side logic on an Intel Cyclone 10 GX FPGA, and is used both for ETROC digital design verification and readout-system development [2302.01548]. CaST couples ray-tracing-derived tap generation to Colosseum’s FPGA channel emulator and a containerized SDR sounder, thereby treating FEMU as a real-time physical-environment emulator whose correctness is established statistically by end-to-end sounding rather than by RTL equivalence alone [2208.03993].

## 6. Open-source ecosystems, common misconceptions, and limitations

Open-source release is a persistent theme in FEMU research, although the granularity varies. EMiX states that it is the first open-source framework to push FPGA-based full-system emulation of many-core RISC-V designs beyond the resource limits of a single board, and documents a repository containing `emix-core`, `bridges`, and `tools`, together with a five-step procedure for reproducing the 8-FPGA Linux-boot setup [2604.27012]. Makinote releases its FPGA shell online at `https://github.com/MEEPproject/fpga_shell` [2401.17984]. NORM provides full VHDL source and usage examples on GitHub [2202.07948]. The neuromorphic platform is explicitly described as an open-source FPGA-based emulation environment [2004.06061]. X-HEEP-FEMU is presented as an open-source and configurable framework with a Python SDK and Jupyter-based orchestration [2508.16981].

One common misconception is that FEMU always implies a monolithic, cycle-exact copy of the eventual silicon system. The literature does not support that view. EMiX seeks transparent multi-FPGA scaling without fundamental RTL redesign [2604.27012], but EmuNoC is deliberately hybrid, with software-only packet generation and hardware clock synchronization [2206.11613]. X-HEEP-FEMU is explicitly cycle-approximate and energy-aware rather than a literal silicon clone [2508.16981]. SCE-MI scan co-emulation pushes scan-control logic into a hardware transactor to reduce communication overhead rather than mapping the full verification environment into RTL [1409.3276]. This suggests that FEMU should be classified by what aspect of system behavior it preserves, not by whether every subsystem is resident in FPGA logic.

The principal limitations reported across FEMU systems are resource capacity, interconnect overhead, debug overhead, and model floors. EMiX still reports Linux boot in 15 min versus approximately 5 min on a single FPGA, despite \(S(8)\approx 7.2\times\) speedup [2604.27012]. Makinote states that partitioning is currently manual/heuristic and identifies inter-FPGA bandwidth and PCIe DMA setup overhead as bottlenecks [2401.17984]. METICULOUS cannot emulate latencies below its approximate 400 ns floor and caps at approximately 450 MB/s per board [2309.06565]. The SCE-MI study reports fixed handshake overhead per transaction and debug-probe inflation reaching up to \(+385\%\) FFs for static debug in simulation acceleration and \(+30\)–\(47\%\) for SCE-MI designs [1409.3276]. Taken together, these results indicate that FEMU remains a constrained optimization between fidelity, speed, visibility, and deployability rather than a universally solved replacement for software simulation or commercial emulation.

Source: https://www.emergentmind.com/topics/fpga-emulation-femu