---
title: 'FireSim: FPGA-Accelerated Cycle-Exact Simulator'
url: https://www.emergentmind.com/topics/firesim
type: topic
---

# FireSim: FPGA-Accelerated Cycle-Exact Simulator

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 [1903.06495; 2103.14951; 2603.26054].

## 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 [1903.06495]. 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 [1903.06495; 2506.11446].

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

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 [2603.26054]. This arrangement allows timing studies that depend on cycle-level behavior, including DRAM timing parameters such as \(t_{RC}\), 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 [1903.06495]. 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 [1903.06495]. 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 [1903.06495].

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 [2603.26054]. 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 \(t_{RC}=47\ \text{ns}\), then validates a theoretical single-bank guaranteed bandwidth of \(1362\ \text{MB/s}\) against a measured \(1271\ \text{MB/s}\) [2603.26054].

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 [2508.12636]. 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 [1903.06495].

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 [2103.14951]. 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 [2103.14951]. 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 [2201.09652].

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 [2506.11446]. 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 [2506.11446]. The study reports up to a 2× performance improvement across various ML models compared with other virtualization approaches, with only 2% hardware cost [2506.11446].

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 [1903.06495] |
| RISC-V virtualization | Pre-silicon hypervisor evaluation | average 1% hosted-execution overhead; ~80 ns bare-metal interrupt latency [2103.14951] |
| Delegated virtualization | Compare DuVisor against KVM | up to 47.96% performance improvement [2201.09652] |
| Inter-core NPU virtualization | FPGA-backed accelerator prototype | up to a 2× performance improvement, with only 2% hardware cost [2506.11446] |

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 [2410.14003]. 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 [2410.14003]. With per-bank regulation, best-effort throughput improves by up to 3.66× over bank-oblivious regulation while maintaining victim protection [2410.14003].

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

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 [2606.27350]. 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 [2509.18472]. 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 [2509.18472].

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 [1903.06495]. The per-bank DRAM study uses a simple direct bank map through bits 9–11 and focuses analytically on \(t_{RC}\) and FR-FCFS, which simplifies bank targeting but does not capture more complex commercial-controller mappings [2603.26054].

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

Source: https://www.emergentmind.com/topics/firesim