CVA6: a RISC-V core where the barrier to running it is the toolchain, not the RTL

Six stages, three privilege levels, and the design goal behind them

CVA6 is described as a six stage, single issue, in order CPU implementing the 64 bit RISC-V instruction set. It fully implements the I, M, A and C extensions as specified in Volume I of the user-level ISA version 2.3, along with the draft privilege extension 1.10, and it provides the M, S and U privilege levels needed to support a Unix-like operating system. It is also compliant with draft external debug specification 0.13.

The microarchitecture list is short and specific: configurable size, separate TLBs, a hardware page table walker, and branch prediction with both a branch target buffer and a branch history table. The stated primary design goal was reducing critical path length, which is a synthesis-driven objective rather than a throughput one, and matches the published paper on a Linux-ready 1.7 GHz 64 bit core that the README cites for academic use.

The core is configurable, which is the feature that matters most in practice. The repository description calls it highly configurable for both application and embedded applications, and the fact that application class configurations can boot Linux means the same RTL serves both ends of the range. Whether a given configuration is application class or embedded is a build parameter, not a fork.

The project sits under the OpenHW Group, and the README points to a separate RESOURCES.md file where ecosystem pointers live: building blocks, designs and partners. That separation of core code from ecosystem information is a deliberate organizational choice and tells you the repository is meant to be one component in a larger open hardware ecosystem rather than a self contained product.

Cloning, the toolchain, and why the build scripts are not optional

The quick setup is for compiling and running a Verilator model of the CVA6 APU inside the testbench at `corev_apu/tb`. It is a seven step list and two of those steps are the real work.

git clone https://github.com/openhwgroup/cva6.git
cd cva6
git submodule update --init --recursive

The recursive submodule update is not optional. The repository uses Bender for dependency management and carries a `Bender.yml`, plus a `.gitmodules`, and `core-v-verif` is defined as a CVA6 submodule. Without them the build fails at configuration time rather than at compile time.

Step two is installing a GCC cross toolchain, and the README attaches a warning to it: it is strongly recommended to use the toolchain built with the provided scripts. Those scripts live in `util/toolchain-builder/`, with separate prerequisites and getting started sections. Steps three through six are the ordinary dependencies: cmake 3.14 or higher, the `RISCV` environment variable pointing at the toolchain installation directory, `help2man` and `device-tree-compiler` from the distribution, and the riscv-dv Python requirements.

export RISCV=/path/to/toolchain/installation/directory

sudo apt-get install help2man device-tree-compiler

pip3 install -r verif/sim/dv/requirements.txt

The last step is where the project becomes opinionated. This command installs a custom Spike and a custom Verilator, and the README is explicit that these versions must be used to simulate CVA6:

# DV_SIMULATORS is detailed in the next section
export DV_SIMULATORS=veri-testharness,spike
bash verif/regress/smoke-tests.sh

A CPU core that only simulates correctly against pinned simulator builds has a real cost, and knowing that before you start is more useful than discovering it on day three.

The directory split that lets you build the core without the APU

The repository's structure is the clearest statement of intent in it. Files under `core` are for the CVA6 core only, and the README states there should be no sources there used to build anything other than the core. Files under `corev_apu` are for the FPGA emulation platform and exclude the core. The core can be compiled stand-alone; the APU depends on the core, not the other way round.

`common` holds source used by both, split into `local` for files hosted in this repository and `submodules` for files hosted elsewhere. `ci` is CI scriptware, `pd` holds example and CI scripts to synthesise the core, `util` is general utility scriptware, and `vendor` holds third party IP maintained outside the repository. `verif` is the verification environment.

Inside `verif`, the four directories map to distinct jobs. `bsp` is a board support package for test programs compiled, assembled and linked for the CVA6, shared by both the core testbench and the `uvmt_cva6` UVM environment. `regress` holds scripts to install tools, test suites and CVA6 code, and to execute tests. `sim` is the simulation environment such as riscv-dv. `tb` holds the testbench module instantiating the core, and `tests` holds the test cases and test lists.

The Makefile at the root shows how many commercial simulators this still accommodates. It has separate library and tool variables for QuestaSim, Verilator and VCS, with `VLOG`, `VSIM`, `VOPT` and `VCOM` suffixed by a `QUESTASIM_VERSION` value, plus a DPI library target. The default top level is `ariane_tb` with a maximum of 10,000,000 cycles for a successful run, and the default board for bitstream generation is `genesys2` with `kc705` and `nexys_video` also supported. The Makefile warns and sets `CVA6_REPO_DIR` for you if you have not, which is a small kindness that saves a confusing failure.

One name is worth flagging. The repository and homepage use CVA6, and the RTL and testbench still carry the older Ariane names, including the `ariane_tb` top level and an `ariane_overview` figure path in the documentation. The academic paper the README cites is also titled under the Ariane name. Expect that mix when you search.

Verification, performance modelling and the tutorials

The verification environment is the largest part of the repository in practice, and it is shared with other cores through a separate `core-v-verif` project on GitHub. The README notes that core-v-verif is defined as a cva6 submodule, which means the same framework serves other designs rather than being written for this core alone.

A `perf-model/` directory is provided and the README describes it as a way to investigate performance related microarchitecture changes. That is a genuinely useful tool for anyone considering a change: it lets you evaluate a pipeline tweak without synthesising and running the full design.

Four tutorials are listed at the top of the README, and they define the four jobs people actually do with this core: running simulations, ASIC implementation, FPGA implementation and running an OS on the FPGA, and instruction tracing. There is also a `docs/` directory with the user manual, published through readthedocs.

Parallel builds are controlled by one environment variable, `NUM_JOBS`, used for all build and simulation script executions. Left undefined it defaults to 1, which means a sequential `make`, and when set explicitly the README recommends not exceeding two thirds of the total number of virtual cores available. That recommendation is worth taking literally, since the default of 1 turning a simulation run into an overnight job is a common first experience with verification environments.

A `Flist.ariane` file at the root and a `src_files.yml` point at file list definitions, and `verilator_config.vlt` at the root configures linting for Verilator. A `spyglass/` directory covers the commercial lint flow, which is how linting is done in the environments this design is verified in.

Licensing, cadence, and what the repository does not tell you

The license metadata for this repository records no recognized identifier, yet the tree contains `LICENSE`, `LICENSE.Berkeley` and `LICENSE.SiFive` at the top level. Three license files is the interesting part: a RISC-V core of this lineage commonly carries both a permissive core license and attribution obligations inherited from specific blocks, and the presence of both Berkeley and SiFive files indicates the design incorporates work covered by each. If you need to know what applies to a particular module, read those three files rather than relying on the repository's license field, which reports nothing it recognises.

On cadence, the repository is not archived and the last push was on 2026-09-23, so development is current. The release tags tell a slightly different story: `cv32a60x-v6.0.0` on 2025-04-23, `v5.3.0` on 2025-02-03 and `v5.2.0` on 2025-01-16. The most recent release is therefore from April 2025 while commits have continued well past it, which is the normal shape for a hardware project where the tag marks a point release and verification continues afterwards. The `cv32a60x` prefix in the newest tag also suggests a specific core variant, since that name refers to a configuration of this design.

Two things the README does not settle are worth naming. There is no FPGA board bring-up detail in the quick setup, so board-specific work is in the tutorial rather than the landing page. And the `RESOURCES.md` ecosystem document is described as gathering pointers to building blocks, designs and partners, which means the surrounding ecosystem changes without this repository changing, so its contents should be treated as a snapshot rather than a current directory.

Editorial conclusion

CVA6 is a good fit if you are building a RISC-V subsystem, evaluating an application class core, or teaching processor design, because it separates core from APU cleanly enough to build either on its own and because the verification environment is part of the repository rather than a separate contract. It is a poor fit if you want to run Linux this afternoon, since the README states plainly that the toolchain built by the provided scripts is strongly recommended and that specific simulator versions must be used. Start by cloning with submodules and building the toolchain first, then read the running simulations tutorial, and treat the `tutorials/asic.md` and `tutorials/fpga.md` guides as the route to hardware rather than a side exercise.

Frequently asked questions

Official sources

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