FireSim: FPGA-Accelerated Cycle-Exact Simulator
- FireSim is a cycle-exact, FPGA-accelerated simulator that uses synthesizable RTL to model RISC-V systems with realistic cache, DRAM, and peripheral timing.
- The simulation decouples host timing from target cycles through techniques like FAME-1 and token-based methods, enabling precise cycle-level behavior studies.
- FireSim facilitates full-system prototyping and hardware/software co-design, supporting research in virtualization, accelerator integration, and memory-system fidelity.
Searching arXiv for foundational and recent FireSim papers to ground the article. arxiv_search(query="FireSim FPGA-accelerated cycle-exact simulator RISC-V Chipyard", max_results=10, sort_by="relevance") arxiv_search(query="FireSim cycle-exact FPGA-accelerated simulation Chipyard Golden Gate FASED", max_results=10, sort_by="relevance") FireSim is a cycle-exact, FPGA-accelerated full-system simulator for RTL-derived RISC-V systems, used to execute Rocket Chip– and Chipyard-based SoCs with realistic cache, DRAM, and peripheral timing. In the literature covered here, it is deployed both on Amazon EC2 F1 instances and on a Xilinx UltraScale+ VCU118 FPGA, and it is used to study complete hardware/software stacks, including Linux, accelerators, hypervisors, and QoS mechanisms, rather than only trace-driven or software-only models (Farshchi et al., 2019, Sá et al., 2021, Sullivan et al., 27 Mar 2026).
1. Architectural identity
FireSim is characterized by a direct relationship between the simulated system and synthesizable RTL. One study describes it as “a fast cycle-exact system simulator which runs on cloud FPGA,” and states that the simulated hardware is derived from the actual RTL of the design, so the same RTL can be pushed through a VLSI flow to fabricate the chip (Farshchi et al., 2019). In practice, FireSim is commonly used with Rocket Chip and Chipyard, with TileLink-based SoCs and configurable memory hierarchies, and it serves as a platform for both in-order Rocket and out-of-order BOOM targets (Farshchi et al., 2019, Feng et al., 13 Jun 2025).
This RTL grounding is central to FireSim’s position in computer architecture research. Rather than approximating a processor with a high-level functional model, FireSim executes a target that is structurally close to an implementation candidate. A plausible implication is that FireSim occupies an intermediate position between RTL simulation and FPGA prototyping: it preserves implementation-level structure while still exposing a configurable full-system simulation environment.
2. Timing model and execution semantics
A defining property of FireSim is that target timing is decoupled from host timing. One paper describes FireSim’s standard FAME-1 transform as adding a global enable signal and an input mux to each register; when enable is deasserted, registers hold their value and the target model is stalled (Farshchi et al., 2019). In the same account, FireSim is described as a token-based simulation in which the target consumes input tokens and produces output tokens each target cycle, and a missing token, such as a delayed memory response, stalls the entire target (Farshchi et al., 2019).
Later work describes the same principle through Golden Gate and FASED. In a FireSim deployment on a Xilinx UltraScale+ VCU118 FPGA, the FPGA host runs at 100 MHz, but Golden Gate and FASED decouple host speed from target timing so that the simulated SoC runs at a configured 1 GHz target frequency (Sullivan et al., 27 Mar 2026). This arrangement allows timing studies that depend on cycle-level behavior, including DRAM timing parameters such as , cache-miss scheduling, and bank conflicts.
The framework also exposes mixed-language integration issues. In the NVDLA integration study, the Rocket/Chisel part of the target can use the standard FAME-1 register transform, whereas the Verilog NVDLA block is stalled by inserting a clock buffer with enable on NVDLA’s clock; when FireSim’s global enable is 0, the NVDLA clock is held low (Farshchi et al., 2019). This shows that FireSim’s timing discipline is not restricted to homogeneous Chisel designs.
3. Memory-system modeling and full-system fidelity
FireSim’s research value depends heavily on its memory-system models. The NVDLA study emphasizes that FireSim adds virtual LLC and DRAM models with realistic timing, configurable independently from the host FPGA’s physical DRAM, and that this avoids the distortion caused by ordinary FPGA prototyping where logic is slow but commodity DRAM remains relatively fast (Farshchi et al., 2019). In that work, the target SoC includes a shared 2 MiB LLC and a 16 GiB DDR3 model with 4 ranks and 8 banks, and the system runs full applications such as YOLOv3 (Farshchi et al., 2019).
Subsequent work extends FireSim’s FASED controller to better match modern DRAM behavior. In the per-bank DRAM regulation study, FASED is extended with separate read and write queues and write batching with configurable high and low watermarks, and the authors report a 3.14× reduction in bus mode switches (Sullivan et al., 27 Mar 2026). The same study uses FireSim to model a 4 GB DDR3, 1 rank, 8-bank memory with FR-FCFS scheduling, direct bank mapping through physical address bits 9–11, and , then validates a theoretical single-bank guaranteed bandwidth of against a measured (Sullivan et al., 27 Mar 2026).
The ecosystem has also expanded toward fully synthesizable memory-subsystem research. MemorySim is presented as an RTL-level memory simulator implemented entirely in Chisel, fully compatible with the Chisel/Chipyard FIRRTL toolchain and MIDAS/FireSim backends, so that memory behavior remains part of the cycle-exact target rather than a host-side co-simulation model (Chaurasia, 18 Aug 2025). This suggests a broader interpretation of FireSim as a downstream evaluation platform for implementation-level memory-controller research, not only for core and accelerator studies.
4. SoC prototyping and hardware/software co-design
FireSim is frequently used as a “virtual SoC lab” for integrating new blocks into realistic RISC-V systems. The NVDLA work attaches NVDLA’s CSB interface to the Peripheral Bus via APB, its DBB master to the Front Bus via AXI, and its interrupt to the PLIC, then evaluates YOLOv3 in a full system. That study reports that NVDLA can sustain 7.5 fps when running YOLOv3 and that sharing the LLC with NVDLA can yield up to 1.56× speedup (Farshchi et al., 2019).
The same pattern appears in virtualization research. The Bao study implements the RISC-V hypervisor extension in Rocket Chip together with virtualization-aware CLINT and PLIC designs, and performs its main evaluation in FireSim at a 3.2 GHz simulation clock (Sá et al., 2021). It reports that hosted execution causes a marginal decrease of performance, with average 1% overhead due to two-stage address translation, and that bare-metal interrupt latency is about 80 ns while trap-and-emulate guest interrupt handling reaches 740 ns and up to 2280 ns under interference (Sá et al., 2021). DuVisor extends this direction by evaluating a delegated-virtualization extension on FireSim and reporting that DuVisor outperforms KVM by up to 47.96% across real-world applications (Chen et al., 2022).
FireSim is also used for accelerator virtualization. The vNPU prototype uses Chipyard+FireSim to evaluate an inter-core connected Gemmini-derived NPU with an on-chip 2D mesh, vRouter route virtualization, and vChunk memory virtualization (Feng et al., 13 Jun 2025). In the FPGA/FireSim configuration, the target has 8 accelerator tiles, 16×16 systolic arrays per tile, 512 KB scratchpad per tile, 4 MB total scratchpad, and 16 GB/s DRAM bandwidth (Feng et al., 13 Jun 2025). The study reports up to a 2× performance improvement across various ML models compared with other virtualization approaches, with only 2% hardware cost (Feng et al., 13 Jun 2025).
A compact view of representative FireSim uses is given below.
| Research area | FireSim role | Representative result |
|---|---|---|
| NVDLA integration | Full-system accelerator evaluation | 7.5 fps on YOLOv3; up to 1.56× LLC-sharing speedup (Farshchi et al., 2019) |
| RISC-V virtualization | Pre-silicon hypervisor evaluation | average 1% hosted-execution overhead; ~80 ns bare-metal interrupt latency (Sá et al., 2021) |
| Delegated virtualization | Compare DuVisor against KVM | up to 47.96% performance improvement (Chen et al., 2022) |
| Inter-core NPU virtualization | FPGA-backed accelerator prototype | up to a 2× performance improvement, with only 2% hardware cost (Feng et al., 13 Jun 2025) |
These case studies indicate that FireSim is most effective when architectural changes must be evaluated under a realistic software stack, but before silicon exists.
5. QoS, interference, and bank-aware resource management
One major line of FireSim-based research concerns shared-memory interference. In the per-bank LLC regulation study, FireSim hosts a heterogeneous RISC-V SoC with one BOOM core, two Rocket cores, a 1 MB SiFive inclusive L2 cache, and a hardware bandwidth regulation unit placed on TileLink Cached edges (Sullivan et al., 2024). This work shows that cache bank-aware denial-of-service attacks can be reproduced in FireSim and that a victim running BkPLLRead suffers a 3.52× slowdown when attackers target the same LLC bank, but only 1.00× slowdown when they target a different bank (Sullivan et al., 2024). With per-bank regulation, best-effort throughput improves by up to 3.66× over bank-oblivious regulation while maintaining victim protection (Sullivan et al., 2024).
The later DRAM-focused study generalizes the argument from LLC banks to DRAM banks. It implements a per-bank memory bandwidth regulator directly in the Rocket inclusive L2 of a 4-core BOOM-based SoC built via Chipyard and evaluated in FireSim (Sullivan et al., 27 Mar 2026). The target uses a 1 MB inclusive L2 with 2 banks and 27 MSHRs per bank, plus a 4 GB DDR3, 1-rank, 8-bank memory model with FR-FCFS scheduling. Using FireSim, the authors show that concentrating traffic on one bank can be much more damaging than high-bandwidth all-bank traffic: in the reported experiment, an all-bank read attack produces a victim slowdown of about 2.1× with attacker bandwidth above 5 GB/s, whereas a single-bank write attack produces about 6.2× slowdown with attacker bandwidth below 1 GB/s (Sullivan et al., 27 Mar 2026). Under per-bank regulation, real workloads in the best-effort domain achieve a 5.74× average throughput improvement over all-bank regulation while preserving the same level of isolation for the real-time domain (Sullivan et al., 27 Mar 2026).
This body of work supports a broader conclusion: FireSim is particularly well suited to questions where implementation-level scheduling, bank mapping, and throttling logic interact with operating-system behavior and application memory-level parallelism.
6. Ecosystem expansion, validation against silicon, and limits
FireSim has increasingly been incorporated into larger co-design frameworks. CHIA presents FireSim as a first-class node type inside agentic hardware/software co-design loops, alongside Chipyard, gem5, ChampSim, Hammer, Vivado, Verilator, and evolutionary coding tools (Cui et al., 25 Jun 2026). In that framework, FireSim serves as the high-fidelity full-system evaluation stage after faster inner-loop tools have performed functional testing or coarse architectural screening. This suggests an emerging methodological pattern in which FireSim acts as a ground-truth or near-ground-truth backend inside heterogeneous research workflows.
At the same time, several studies document fidelity limits. The simulator-to-silicon comparison paper models a Banana Pi BPI-F3 and a MILK-V Pioneer in FireSim and concludes that, although FireSim provides valuable insights into architectural performance trends, discrepancies remain between simulated and measured runtimes because of both inherent limitations of the simulation environment and the restricted availability of detailed performance specifications from CPU manufacturers (Barai et al., 22 Sep 2025). Specific issues mentioned there include the absence of DDR4 and LPDDR4 timing models in the evaluated configuration, the need to approximate them with DDR3 FR-FCFS models, and a simplified LLC model that behaves like an SRAM rather than a latency-detailed last-level cache (Barai et al., 22 Sep 2025).
Other works expose additional assumptions. The NVDLA integration study notes that current FireSim requires all hardware blocks to have synchronous clock sources, so NVDLA is modeled at the same frequency as the cores even though a real chip may operate the accelerator at a lower frequency (Farshchi et al., 2019). The per-bank DRAM study uses a simple direct bank map through bits 9–11 and focuses analytically on and FR-FCFS, which simplifies bank targeting but does not capture more complex commercial-controller mappings (Sullivan et al., 27 Mar 2026).
A frequent ambiguity concerns the name itself. In robotics literature, “Fire as a Service” is an asynchronous co-simulation framework that augments robot simulators with thermally and visually accurate fire dynamics; despite occasional informal use of “FireSim” in that context, it is a different system from the FPGA-accelerated RISC-V platform discussed here (Wagner et al., 19 Mar 2026). The dominant computer-architecture usage of FireSim therefore refers not to fire-environment simulation, but to RTL-derived, cycle-exact full-system simulation for architecture, systems, and accelerator research.