Chipyard: a Chisel-based RISC-V SoC design framework from UC Berkeley

What problem Chipyard solves, and who it is actually for

Building a RISC-V system-on-chip from scratch means assembling a core, a memory hierarchy, a bus, peripherals, an interrupt controller and a simulation harness, then keeping all of those pieces compatible as each one moves. Chipyard exists to remove that assembly work. The README describes it as "an open source framework for agile development of Chisel-based systems-on-chip" that lets you use the Chisel HDL, the Rocket Chip SoC generator and other Berkeley projects to produce a RISC-V SoC spanning MMIO-mapped peripherals through custom accelerators.

The target user is a hardware researcher or an advanced graduate student, not a firmware engineer looking for a prebuilt core. The framework bundles processor cores (Rocket, BOOM, CVA6/Ariane), vector units (Saturn, Ara), accelerators (Gemmini, NVDLA), memory systems and peripherals. Choosing among those is a configuration decision inside a Scala generator, not a vendor dropdown. If you want to tape out a fixed Cortex-class design, this is the wrong layer of the stack.

The project is developed by the Berkeley Architecture Research Group in the Electrical Engineering and Computer Sciences Department at UC Berkeley. The repository is not archived, and the most recent push recorded on the default branch was 2026-09-25. The newest listed release is 1.14.0, dated 2026-06-22; before that, 1.13.0 landed on 2024-09-30, so the release cadence is roughly annual with patch releases in between.

How the generator flow works: Chisel, FIRRTL, and a submodule umbrella

The mechanism is elaboration. You describe a system in Scala using Chisel, and the generator elaborates that description into FIRRTL, which is then lowered to Verilog. Nothing about the SoC is hand-written RTL at the top level; the top level is a configuration object. That is why the repository's primary language is Scala and why the build file at the root is build.sbt.

Chipyard itself is mostly glue. The generators/ directory holds the submodules, and .gitmodules at the root lists them, which means a plain clone gives you empty directories until submodules are initialised. The sims/ directory holds simulation targets, fpga/ holds FPGA-related material, vlsi/ holds the Hammer integration for automated VLSI flows, software/ holds workload and bare-metal or Linux build support, and toolchains/ holds the RISC-V toolchain build. The README names four concurrent flows: software RTL simulation, FPGA-accelerated simulation through FireSim, automated VLSI flows through Hammer, and software workload generation through FireMarshal.

The consequence of the umbrella layout is that version compatibility is the framework's central job. Rocket Chip, BOOM, Gemmini, FireSim and Hammer each have their own upstream repositories and their own release histories. Chipyard pins a combination that is known to elaborate together. When you update one submodule on your own, you are outside that tested combination, and the documentation's version selector is the only place that tells you which docs match which release.

Installing Chipyard and running a first simulation

The README does not reproduce install steps. It points to https://chipyard.readthedocs.io/ for getting started, and the repository root carries the pieces that documentation describes: build-setup.sh, conda-reqs/, dockerfiles/, build.sbt, common.mk and variables.mk.

The setup script is the entry point. It is a shell script at the repository root, and the conda-reqs/ directory exists to pin the Python and tool dependencies the flow expects. Run it from the repository root after cloning with submodules:

git clone https://github.com/ucb-bar/chipyard.git
cd chipyard
./build-setup.sh

Because generators/ is populated through .gitmodules, a clone that skips submodule initialisation leaves you with an unbuildable tree. The setup script handles the submodule and toolchain work; the documentation, not the README, is where the flags and the environment sourcing are described.

Once the toolchain is in place, the build is an sbt build. The root build.sbt is the Scala build definition, and common.mk and variables.mk are the make-level variables that the simulation makefiles in sims/ consume. A first real use is to elaborate and simulate a default configuration rather than to write new hardware. The documentation site is the source for the exact make target names and for the generated simulator path, and the README's quick links point there rather than duplicating them.

The FPGA-accelerated path is different enough to be worth separating. FireSim is a distinct project with its own tutorial, linked from the README at https://fires.im/tutorial-recent/, and the fpga/ directory in this repository is not a substitute for that tutorial. If your goal is FPGA-accelerated simulation rather than software RTL simulation, start from the FireSim tutorial, not from build-setup.sh alone.

Where Chipyard stops being the right tool

The sharpest limitation is the one the README states indirectly by calling this a framework for Chisel-based development. If your team does not write Chisel, the framework's main value proposition does not apply to you. You would be using a Scala generator to produce Verilog you then hand-edit, which is a workflow the project is not organised around.

The second limitation is build weight. A full setup pulls a RISC-V toolchain, a conda environment, submodules for every bundled generator, and a Scala build. The dockerfiles/ directory exists precisely because reproducing that environment by hand is fragile. On a machine without the expected toolchain, elaboration failures surface as Scala or FIRRTL errors that do not obviously point at the missing dependency.

The third is release cadence. With 1.13.0 in September 2024 and 1.14.0 in June 2026, the tagged releases are not frequent. If you need a fix that landed on main between releases, you are tracking a branch rather than a version, and the README does not document a supported backport path for that.

Finally, Chipyard is an integration layer, so it inherits the maturity of everything under it. NVDLA is linked as an external project with its own governance; CVA6 comes from OpenHW Group. Selecting a configuration that combines a less-travelled core with a less-travelled accelerator is where you should expect to spend debugging time, and the documentation's coverage of every pairwise combination is necessarily uneven.

Chipyard against hand-assembled Rocket Chip

The closest alternative is to use Rocket Chip directly, without Chipyard around it. Rocket Chip is itself a Chisel SoC generator, and the README links it as a component. The difference in approach is scope of integration. Rocket Chip gives you the core, the tile and the coherence fabric; you supply the peripherals, the simulation harness, the workload build and the physical design handoff yourself.

Chipyard's answer is to ship those as part of the same tree: FireMarshal for bare-metal and Linux workload generation, FireSim for FPGA-accelerated simulation, Hammer for VLSI, and a peripheral set already wired into the example configurations. That is a real difference in effort, and it is why the README can list four concurrent development flows as one framework's feature rather than four separate projects.

The cost of that integration is coupling. With Rocket Chip alone you upgrade the core on your own schedule. With Chipyard, the core version is one input to a combination that also includes BOOM, Gemmini and the simulator, and the framework's tested combinations are the ones the release tags describe. If you only ever need Rocket and a UART, the extra machinery is overhead. If you need BOOM plus Gemmini plus FireSim plus a Hammer target, assembling that by hand is the larger project.

Maintenance, release cost, and what the licence does not cover

The repository is not archived and the last push on the default branch was 2026-09-25, so the tree is moving. The tagged releases are the stable points: 1.14.0 on 2026-06-22, 1.13.0 on 2024-09-30, and 1.12.3 on 2024-08-21. The gap between 1.13.0 and 1.14.0 is the number to plan around. If your project needs a feature that is not in the latest tag, you are on main until the next release.

Upgrade cost is dominated by submodules. Because generators/ is populated from .gitmodules, moving to a new Chipyard release moves every bundled generator at once. A change in the Rocket Chip or BOOM interface can therefore show up in your configuration code rather than in the framework's own code, and the CHANGELOG.md at the root is where the release notes live.

The repository carries LICENSE with BSD-3-Clause for Chipyard itself, and a separate LICENSE.SiFive file at the root. The presence of a second licence file is the signal that the tree is not uniformly licensed. Chipyard aggregates submodules from several organisations, including OpenHW Group for CVA6 and the external NVDLA project, and each of those carries its own terms. The README does not enumerate the licence of every bundled generator. If you intend to ship a design derived from a particular configuration, check the licence of each submodule that configuration pulls in rather than assuming the root BSD-3-Clause covers all of it. This is not legal advice; it is a statement about what the repository does and does not document.

Editorial conclusion

Adopt Chipyard if you are a research group or an advanced hardware team that already writes Chisel or is willing to learn it, and you need Rocket, BOOM, Gemmini, FireSim and Hammer wired together rather than assembled by hand. Do not adopt it if you want a fixed RTL core you can drop into a conventional Verilog flow, or if you cannot commit to the conda-based toolchain and the submodule build. Before starting, check the Chipyard documentation version selector against the release tag you intend to use, and confirm which of the bundled projects your design actually pulls in, because the repository is a submodule umbrella and each one carries its own licence and its own release cadence.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. ucb-bar/chipyard on GitHub