FireSim: cycle-accurate hardware simulation on FPGAs, from one board to hundreds of cloud instances

A simulator whose output has to match the silicon

FireSim is an FPGA-accelerated full-system hardware simulation platform. The description in the project documentation is precise about what that buys you: it makes it easy to validate, profile and debug RTL hardware implementations at 10s to 100s of MHz, and it simplifies co-simulating ASIC RTL with cycle-accurate hardware and software models for other system components such as I/Os.

The last clause is the one that separates this from an ordinary RTL simulator. In a cycle-accurate simulation, the model of a DRAM controller has to advance in step with the processor's clock, down to the timing of the memory controller's response. If the model is late by a cycle, the software running on top will take a different branch than it would in silicon. FireSim's claim is that the performance results match an ASIC implementation of the same design, and that users can write their own RTL, processors and accelerators, and run it at near FPGA-prototype speeds.

The audience is therefore a hardware architecture group, not a web developer. The project's publication record is the evidence for that: users across academia and industry at more than 20 institutions have published over 40 papers using FireSim, in computer architecture, systems, networking, security, scientific computing, circuits and design automation, and the documentation says FireSim has also been used in the development of shipping commercial silicon.

FireSim was originally developed in the Electrical Engineering and Computer Sciences Department at the University of California, Berkeley, and now has industrial and academic contributors from around the world.

One Alveo board on a desk, or hundreds of EC2 F1 instances

The deployment model is the most distinctive thing about FireSim, and the documentation describes both ends of the same scale.

At the small end are individual SoC simulations hosted on on-prem FPGAs, and the example given is a single Xilinx Alveo board attached to a desktop. At the large end are massive datacenter-scale simulations harnessing hundreds of cloud FPGAs, with Amazon EC2 F1 given as the example.

That range is the point. A simulation that runs one SoC on one board and a datacenter spanning thousands of nodes on hundreds of cloud FPGAs is the same platform, and the same user-facing workflow, which is unusual in hardware tooling where scaling usually means a different tool. The on-prem and cloud split is what makes the tool usable for an academic group with a board and a company with a budget, and it is why the project tagline talks about on-prem and cloud flexibility.

What runs on the FPGA is the design under test, and the cycle-accurate models sit alongside it. To help construct a closed and deterministic simulated environment around a design, FireSim includes validated and high-performance hardware and software models for I/Os like DRAM, Ethernet, Disks and UART, among others. Users can also integrate custom software models for components they would rather not write as RTL.

The deterministic closed environment is what makes a multi-node datacenter simulation meaningful. If the network and the memory behaved nondeterministically, a thousand node run would not be reproducible, and a result would not be debuggable.

RISC-V, BOOM and Chipyard out of the box, plus a Linux you can log into

FireSim was originally developed to simulate datacenters by combining open RTL for RISC-V processors with a custom cycle-accurate network simulation, and that origin still shapes the defaults.

By default, the project provides all the RTL and models necessary to cycle-exactly simulate from one to thousands of multi-core compute nodes, derived directly from silicon-proven and open target RTL, namely RISC-V, Rocket Chip, BOOM and Chipyard, with an optional cycle-accurate network simulation tying them together. If you are designing a RISC-V core or a datacenter built from these blocks, the starting point is already there.

The workload story is the other half. FireSim also provides a Linux distribution, the separately released FireMarshal, that is compatible with the RISC-V systems it simulates and automates the process of including new workloads into that distribution. The documentation states that these simulations run fast enough to interact with Linux on the simulated system at the command line, like a real computer, and that users can even SSH into simulated systems and access the internet from within them.

That capability is what turns FireSim from a verification tool into a systems tool. A cycle-accurate simulation where you can log in and run a workload is a platform for studying a whole machine, not just for checking a waveform.

The design side is open as well. FireSim can simulate arbitrary hardware designs written in Chisel or in Verilog, so a team is not locked into the Berkeley toolchain, although the surrounding infrastructure, the models and the workload distribution are built around the RISC-V targets.

The repository layout tells you what the build involves

FireSim is a large repository and the directory names are the honest summary of what a build involves.

The root carries `build-setup.sh` and `build-setup-nolog.sh`, which are the setup scripts, and a `conda-reqs/` directory holding the environment requirements, which tells you the build is not a plain sbt invocation. There is a `sourceme-manager.sh` and a `gen-tags.sh`, so the environment is managed through a sourcing mechanism rather than an implicit shell state.

Then the substance: `sim/` holds the simulator itself, `target-design/` holds the designs and models being simulated, `platforms/` holds the platform definitions, `deploy/` holds the deployment configuration for the various targets, `regression/` holds the regression infrastructure, `scripts/` holds the helper scripts, and `utils/` holds shared utilities. `docs/` holds the documentation source, which is published to docs.fires.im, and `CHANGELOG.md` tracks the changes. The `.clang-format` and `.clang-tidy` files apply to the native code, and `.mergify.yml` suggests the merge automation is handled by a bot.

The build inputs are spread across all of that, which is why the project points new users at the getting-started guide rather than at a one line command. It is a research-grade tool with a real dependency chain, not a library you add to a build file.

Where to get it, and where to ask

The project does not document an install command in its readme, and it does not need to, because the entry point is the documentation rather than a package index.

The getting-started guide lives at docs.fires.im, the project site is fires.im, and the Scala API documentation is published separately at fires.im/firesim/latest/api/. The readme is explicit that the codebase is open source at github.com/firesim/firesim, that pull requests and issues are welcome, and that help is available from the FireSim user forum on Google Groups.

There is also a substantial training programme, which is unusual and useful. The project runs tutorials at conferences and events, keeps the most recent slide decks at fires.im/tutorial-recent, and points to the 2023 FireSim and Chipyard User/Developer Workshop at ASPLOS, whose talk videos are on the workshop page and on a YouTube playlist. There is also a recent overview talk on YouTube and a LatchUp 2023 update talk.

The readme cautions that you should still follow docs.fires.im for the up to date getting-started guide rather than relying on the slide decks, which is a reasonable warning given that slide decks age badly and the tool chain moves.

For anyone evaluating the project rather than using it, the ISCA 2018 paper, FireSim: FPGA-Accelerated Cycle-Exact Scale-Out System Simulation in the Public Cloud, is linked with a PDF, an IEEE Xplore entry, an ACM DL entry and a BibTeX file, and it was selected as one of IEEE Micro's Top Picks from Computer Architecture Conferences in 2018. There is also an ISCA-50 retrospective paper linked.

Where FireSim is the wrong tool

The limits are physical and budgetary, and they are not close.

The first is that FireSim needs an FPGA. That is the whole architecture. The performance comes from running the design on real FPGA fabric, so a simulation without an FPGA is not a degraded FireSim, it is a different tool. The options are an on-prem board such as the Xilinx Alveo mentioned in the documentation, or cloud FPGA instances such as Amazon EC2 F1. Either way, someone is spending money on hardware for the duration of the work, and a team without a board and without a cloud FPGA budget cannot use this.

The second is that it is not a functional simulator. Cycle accuracy is the point, and it costs FPGA time, which costs money, and it is a poor trade for a design that only needs to be checked for logical correctness. There are far cheaper ways to run a functional simulation of RTL, and for a project whose real question is does this design compute the right answer, FireSim is the expensive answer.

The third is the toolchain weight. The build spans conda requirements, a Scala and Chisel toolchain, native C++ components with clang-format and clang-tidy configuration, a platform and deploy tree, and a regression harness. A design team that is not already in the Chipyard or Chisel world will spend real time on the setup, and the readme sends you to the getting-started guide for it.

The fourth is scope. The default models and the workload distribution are built around RISC-V targets, and the multi-node story is built around the datacenter network simulation. A team simulating something else can do it, since arbitrary Chisel and Verilog designs are supported and custom models can be integrated, but they are building more of the environment themselves.

A custom licence, a regular release line, and a wide user base

On licensing, the licence is listed as a custom one that GitHub cannot classify, with the terms in the `LICENSE` file at the root, and the readme does not restate the terms. For a tool that sits inside a chip development flow, the licence text is the document to read before you build a process around it, and it is the one place the readme leaves a question open rather than answering it.

The release record is a good sign for a project with this kind of hardware dependency. Version 1.22.0 was published on 2026-10-15, 1.21.0 on 2026-06-22, and 1.20.1 on 2024-08-21, with the last push to the repository on 2026-10-15, the same day as the newest tag. Regular minor releases with occasional patches are what a tool that tracks new Chisel and simulator versions should look like.

The community around it is broad. There is a user forum, a Twitter account for project updates, a blog at fires.im/blog, a user publications page, and a changelog linked from the readme. The readme also records a first FireSim and Chipyard User/Developer Workshop at ASPLOS 2023, held on March 26, 2023, as a full day of talks from users and developers, which is a reasonable proxy for how the community is organised: around workshops, papers and a mailing list rather than around a company.

The project also points at a separate FireMarshal repository for the Linux distribution it uses, so the two pieces are versioned and released somewhat independently, which is worth remembering when planning an upgrade.

Editorial conclusion

FireSim fits a hardware architecture team that needs cycle-accurate results from a full system, from a single Xilinx Alveo board on a desk to a datacenter design spanning thousands of nodes, and that wants to debug and profile RTL at a speed where software workloads can actually run. It does not fit a team that needs only functional verification, since its value is the cycle accuracy and the FPGA speed rather than a fast simulator, and it is the wrong choice if you have no FPGA budget, on-prem or in the cloud. Before you start, read the getting-started guide at docs.fires.im and the LICENSE file, because the licence is listed as a custom one rather than a standard open source licence.

Frequently asked questions

Official sources

1. firesim/firesim on GitHub
2. Issues
3. Project website
4. README
5. Releases