Gemmini: Berkeley's Scala-Based DNN Accelerator Platform

Gemmini’s DNN Accelerator Scope

Gemmini addresses a specific hardware research problem: evaluating how a DNN accelerator behaves as part of a complete computing system. The README describes it as a “full-system, full-stack DNN hardware exploration and evaluation platform,” rather than a standalone matrix multiplication library. Its intended users are architects who want to understand the relationship between accelerator design, software, memory transfers, system configuration, and overall DNN performance.

The project targets workload analysis and design exploration. It can be used to build different accelerator configurations, write Gemmini programs, use custom data types, and inspect performance counters. The repository also includes software tests for large DNN models such as ResNet50 and smaller matrix multiplication tests. This makes it useful when the question is not only how quickly an array can multiply matrices, but also how data moves between memory, SRAM, and the accelerator during an end-to-end workload.

Gemmini is part of Chipyard and is developed in Chisel, a Scala-based hardware description language. That relationship matters for adoption. Gemmini is not presented as a standalone chip that can be installed independently. Its normal use path depends on Chipyard, Rocket or BOOM tiles, RISC-V software, and simulators such as Spike, Verilator, VCS, or FireSim.

Systolic Array, Scratchpad, and DMA Data Flow

Gemmini is implemented as a RoCC accelerator with non-standard RISC-V custom instructions. It connects to the RoCC port of a Rocket or BOOM tile and, by default, reaches the memory system through the System Bus, which the README identifies as a direct connection to the L2 cache.

The accelerator’s main computation structure is a systolic array for matrix multiplication. The default design supports both output-stationary and weight-stationary dataflows, and programmers can select between them at runtime. The design can also fix the dataflow when the hardware is elaborated. This is a meaningful design choice because data movement requirements differ between the two modes. A user experimenting with accelerator organization can therefore compare runtime-selected behavior with a hardware-fixed configuration.

Inputs and outputs are held in an explicitly managed scratchpad composed of banked SRAMs. A DMA engine transfers data between host-visible main memory and this scratchpad. Weight-stationary operation requires an accumulator outside the array, so Gemmini adds a final SRAM bank with adder units. The accelerator can write results to any accumulator address, read new inputs from accumulator addresses, and use DMA to transfer data directly between the accumulator and main memory. The README specifically notes that direct loading is often necessary for biases.

Peripheral circuitry can apply activation functions such as ReLU and ReLU6, scale results down by powers of two for quantized workloads, and transpose matrices before the systolic array consumes them. These functions are part of the documented architecture, but the README does not provide a complete instruction listing or configuration matrix for every option.

Chipyard Installation and First Simulator Run

The documented setup starts with installing Chipyard dependencies, then installing Chipyard and Spike. The README requires checking out the correct Chipyard and Spike commits. Those exact commit identifiers are not included in the README, so the setup should not be reduced to an unverified sequence of commands.

Install the Chipyard environment and Gemmini’s software library with the following commands. The `source env.sh` command activates the Chipyard environment before the Gemmini library install.

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

source env.sh

cd generators/gemmini
make -C software/libgemmini install

Build the Gemmini software tests after the library installation. The README says the resulting RISC-V binaries appear under `build/` for baremetal, Linux, and proxy-kernel environments.

cd chipyard/generators/gemmini/software/gemmini-rocc-tests
./build.sh

Build a cycle-accurate Verilator simulator with `GemminiRocketConfig`. The README also documents a debug build for waveform generation. The generated SoC Verilog is placed in `generated-src/`.

cd chipyard/sims/verilator
make CONFIG=GemminiRocketConfig

make debug CONFIG=GemminiRocketConfig

For a first functional run, use Spike with the Gemmini extension and a built binary. The README gives separate commands for a proxy-kernel ResNet50 workload and a baremetal ResNet50 workload.

cd chipyard/sims/verilator

spike --extension=gemmini pk ../../generators/gemmini/software/gemmini-rocc-tests/build/imagenet/resnet50-pk

spike --extension=gemmini ../../generators/gemmini/software/gemmini-rocc-tests/build/imagenet/resnet50-baremetal

For a smaller baremetal workload on the cycle-accurate simulator, the documented command uses `run-binary` and points to `template-baremetal`.

cd chipyard/sims/verilator
make CONFIG=GemminiRocketConfig run-binary BINARY=../../generators/gemmini/software/gemmini-rocc-tests/build/bareMetalC/template-baremetal

The README says Linux binaries are dynamically linked, support all syscalls, and are typically run on FireSim. Baremetal binaries lack most syscall support and virtual memory. Proxy-kernel binaries support virtual memory but have limited heap space, so workloads that work in baremetal or Linux can fail there.

Simulator Choice Changes the Result

Gemmini provides different simulator paths for different research questions. Spike is described as much faster than cycle-accurate simulators such as Verilator and VCS. Its boundary is equally important: Spike can verify functional correctness, but it cannot provide accurate performance metrics or profiling information.

Verilator and VCS are therefore relevant when an experiment requires cycle-level behavior. The README’s GemminiRocketConfig command creates a cycle-accurate Verilator simulator, while the debug configuration can generate waveforms. These are research and debugging tools rather than an application deployment path.

FireSim covers a different scale of use. The README identifies it as an FPGA-accelerated cycle-accurate simulation platform and says Gemmini users use it for end-to-end DNN workloads that would take too long on Verilator or VCS. It also supports checking hardware and software behavior in a Linux environment. The README does not give FireSim installation commands, so adopting that route requires following the linked FireSim documentation separately.

The practical limitation is that a functional run is not a performance result. If an architecture decision depends on counters, timing, or workload behavior under cycle-accurate simulation, running only Spike does not answer that question.

Gemmini Versus a Standalone Matrix Multiplication Library

The main alternative is a software-only DNN matrix multiplication library running on a conventional CPU or a separately managed accelerator runtime. The approach differs in where configuration and control live. A software library selects kernels and schedules host computation, while Gemmini exposes a hardware accelerator through custom RISC-V instructions, a RoCC interface, SRAM scratchpads, and DMA-controlled movement.

Gemmini is the better fit when the question concerns accelerator architecture itself, such as systolic-array dataflow, banked SRAM organization, quantization support, accumulator placement, or hardware and software interaction. A standalone library is simpler when the goal is to execute a model without changing hardware or compiling a Chipyard system.

The trade-off is system complexity. Gemmini requires Chisel, Chipyard, RISC-V software, simulator setup, and configuration decisions. Its tests expose the consequences of those choices, including heap constraints in proxy-kernel mode and the performance limits of functional simulation. It is consequently a hardware exploration platform rather than a drop-in inference package. The README does not claim that Gemmini is production-ready silicon or a complete deployment image, so those uses cannot be inferred from the repository description.

Maintenance, Licensing, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-10-14. The release information in the repository lists v0.7.1 on 2023-05-22, v0.7.0 on 2022-11-28, and v0.6.4 on 2022-03-07. This shows a sequence of public releases, but the README does not define a compatibility policy for those releases. The exact commit relationship between Gemmini, Chipyard, and Spike is also described as important, so upgrading one component without checking the documented integration is a real risk.

The repository uses a custom license that GitHub cannot classify. The project points readers to the `LICENSE` file. The README does not reproduce its terms, so it does not support a reliable statement about redistribution, modification, patent rights, or commercial use. License review must be based on the actual file rather than the repository’s “Other” classification. This is a licensing boundary, not a conclusion that the license is permissive or restrictive.

The main upgrade cost is integration cost. Gemmini’s generated configurations, Chisel sources, simulator targets, and software tests depend on a compatible Chipyard setup. The documented quick start also requires specific commits, but those values are not present in the README. The first maintenance task for an adopting group is therefore to compare the checked-out Gemmini, Chipyard, and Spike revisions against the project instructions.

Editorial conclusion

Gemmini fits architects and research teams evaluating DNN accelerator designs inside a complete RISC-V system, especially those already using Chipyard or Chisel. It is a poor fit for someone needing a packaged production accelerator or a turnkey application runtime, since the documented workflow requires source builds, custom configurations, and simulator knowledge. Before adoption, verify the required Chipyard and Spike commits, the custom LICENSE file, simulator availability, and whether the workload fits the selected Linux, baremetal, or proxy-kernel memory model. The project-specific first check is the documented Chipyard integration path in `chipyard/generators/gemmini`.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ucb-bar/gemmini on GitHub