# core-v-verif and the discipline of a shared verification environment

> core-v-verif is the functional verification project for the OpenHW Group CORE-V RISC-V cores, holding UVM testbenches, common simulation makefiles and the documentation that ties them together. Its value is that several cores share one environment, and its cost is that you are adopting a verification culture as much as a set of files.

**openhwfoundation/core-v-verif** — Functional verification project for the CORE-V family of RISC-V cores.

- Repository: https://github.com/openhwfoundation/core-v-verif
- Website: https://docs.openhwgroup.org/projects/core-v-verif/en/latest/index.html
- Stars: 732 · Forks: 332
- Language: Assembly
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/openhwfoundation-core-v-verif

## One environment shared by several CORE-V cores

core-v-verif is described as a functional verification project for the CORE-V family of RISC-V cores, and the repository description is deliberately narrow about that. It is not a general RISC-V verification framework and it is not a collection of standalone testbenches.

The structure shows the shared-environment idea directly. There are core-specific directories for cv32e40p, cv32e40x, cv32e40s and cva6, each holding the verification code for that core. Above them sit mk, described as common simulation Makefiles that support testbenches for all CORE-V cores, and lib, described as common components for all the CORE-V verification environments. Two more directories round it out: vendor_lib, for verification components supported by third parties, and vendor, alongside util and tools at the root.

So the structure is a two-level split. Anything a specific core needs lives in the core directory, and anything every core needs lives in the shared layers. A team adding support for a new CORE-V core writes against the common library rather than copying an environment.

The primary language recorded for the repository is Assembly, which reflects the reference assembly test suites sitting alongside the SystemVerilog and UVM environment, and the topics list names risc-v, systemverilog, uvm and verification.

## Bender manages dependencies, and the manifest follows the parent project

Dependency management for the hardware sources is handled by Bender, described as a dependency management tool for hardware design projects which provides a way to define dependencies among IPs, execute unit tests, and verify that the source files are valid input for various simulation and synthesis tools. The project points at the Bender repository for installation and usage.

The interesting detail is how Bender is used here, and it is unusual enough to trip people up. The project is mainly used as a submodule, as in cvfpu-uvm, and the Bender.yml file, which is the main package manifest holding metadata, dependencies and source file lists, contains the target corresponding to the top project. All the core-v-verif files needed as dependencies for the main project that includes core-v-verif are reported under that target.

In other words, core-v-verif is normally consumed from above rather than run from inside itself. You do not clone it and run Bender locally to get a working simulation in the usual case. You add it as a submodule to your own project, and your project's manifest selects the core-v-verif target it needs. If you are coming from a project where the manifest is the root of everything, that inversion takes a moment to absorb.

The Bender command for generating the list of compilation files is not run by hand. It is included in the compile.py Python parser file, so the file list is produced through the project's own tooling.

## There is no install command, only a documented path in

The getting started section of the project guide is short and it does not contain an install command. It asks first-time users to look at the OpenHW Group website to learn who the organisation is and what it does, and then points at the Quick Start Guide in the CORE-V-VERIF Verification Strategy as the best place to start.

That is deliberate for this kind of project. There is nothing to pip install or fetch as a binary, because the deliverable is a source tree of testbenches, makefiles and documents that has to be wired to a simulator, a toolchain and the RTL of the core you care about. The three prerequisites the project names are Bender for the dependency and file lists, a simulation tool capable of running the SystemVerilog and UVM environment, and the RTL of the core itself.

The first concrete step is therefore a clone into the core-v-cores directory, which is empty in the repository and expects the design sources to be placed there. The Bender repository carries its own installation instructions, and the project deliberately links out rather than restating them.

The consequence for a reader is that the documentation is the setup guide. There is no quick path, and the Quick Start Guide in the verification strategy document is where the actual steps live.

## The core-v-cores directory is empty by design

One directory in the layout needs explaining before anyone tries to build anything. core-v-cores is described as an empty sub-directory into which the RTL from one or more of the CORE-V-CORES repositories is cloned.

This is a deliberate separation of verification from design. The verification environment does not vendor the RTL it checks. Instead you bring in the core source yourself, which means the same verification code can be pointed at different core revisions, and the mapping between a published verification result and the exact RTL it was run against stays in your control rather than being frozen into a submodule.

The trade-off is that a fresh clone is not runnable. There is nothing to simulate until the RTL is dropped in, and the environment documentation and the core's own documentation have to be read together.

The git metadata at the root supports the same idea. The repository carries .gitmodules and .metrics.json, alongside a MergeTest.md file and a GitCheats.md file, which suggests the project's own workflows around merging and history manipulation are documented for contributors rather than left to habit.

## The documentation directory holds the DV plans and the style rules

The docs directory is described as the source for the Verification Strategy document, DV plans, coding style guidelines and available coverage reports. That list is what separates a verification project from a pile of testbenches, and it is the part a new user should read first.

The Verification Strategy document is also where the project directs first-time users, through the Quick Start Guide inside it, while the top-level project guide sends new readers to the OpenHW Group's own website first for background on the organisation. There is no quick start in the repository guide itself, which is unusual but consistent with a project whose audience is verification engineers rather than casual visitors.

Two of the style documents matter for anyone contributing. The contributing guidance points to both CONTRIBUTING and a separate SV/UVM coding style guidelines file in the docs directory. So the expectation is SystemVerilog and UVM code written to a stated convention, not merely code that compiles.

The project also asks contributors to split large contributions into smaller commits, to write meaningful commit messages, and to fixup and rebase if asked, with the stated reason that it eases review. Individual work items are defined as issues with a task label, and the current needs are visible on the GitHub projects associated with the repository.

## A licence that is deliberately not one of the usual ones

The licensing here needs care, because it is not a single standard licence. The repository is recorded under a custom classification that GitHub cannot categorise, and the file is LICENSE.md.

The header comment carried in the source files makes the position explicit:

```text
 Copyright 2020, 2021 OpenHW Group

 Licensed under the Solderpad Hardware Licence, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
 You may obtain a copy of the License at

     https://solderpad.org/licenses/

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.

 SPDX-License-Identifier: Apache-2.0 WITH SHL-2.0
```

 The project is licensed under the Solderpad Hardware Licence, Version 2.0, with the copyright line reading 2020, 2021 OpenHW Group, and the SPDX identifier given as Apache-2.0 WITH SHL-2.0. That combination is the standard way to say Apache 2.0 terms with the Solderpad Hardware Licence as an additional grant, and the file header carries the same Solderpad 2.0 text with its copyright notice.

For an organisation using this in-house, the practical difference from Apache 2.0 is not dramatic but it is real. The Solderpad Hardware Licence is aimed at hardware and firmware and, as the name suggests, carries terms that recognise patent and hardware context rather than the software-only framing of Apache 2.0. Whether the combination suits a particular corporate policy is a question for legal review.

The project also ships CODE_OF_CONDUCT.md and ACKNOWLEDGEMENTS.md at the root, and points contributors at the acknowledgements file, which is the norm for a multi-company project where contributions come from several member organisations.

## The public record is older than the work

The repository tags and the commit history tell two different stories, and a reader should not conflate them.

The listed releases are cv32e40p_v1.8.3 from 2024-07-11, cv32e40p_v1.8.2 from 2024-06-10 and cv32e40p_v1.8.1 from 2024-05-06. All three are named after a specific core version rather than the project itself, which tells you the tags exist to pin a verification environment to a core release.

The news entries inside the project guide are older still and are commented out of the visible text. They record that the verification environment for cv32e40s was up and running on 2021-07-15, the same for cv32e40x on 2021-03-23, and that cv32e40p_v1.0.0 of core-v-verif was released on 2020-12-16, a tag that clones the v1.0.0 release of the CV32E40P core and is intended to let you reproduce the verification environment as it existed at RTL Freeze. More history is kept in the NEWS_ARCHIVE.md file at the root.

Against that, the last push to the repository was on 2026-10-19, so the work is current even though the newest tag is from 2024. The practical reading is that development is continuous on master while versioned tags are cut around specific core releases, so a project that wants a reproducible environment should pick a tag deliberately rather than tracking master.

## Where this project stops being the right answer

The first mismatch is core family. Everything shared here, the common makefiles in mk and the common components in lib, is described as supporting CORE-V cores. Pointing this environment at a RISC-V core from another organisation means working against the assumptions baked into those shared layers, and the Bender target arrangement makes that even harder since your manifest selects a core-v-verif target rather than reusing pieces of it.

The second mismatch is expectation of a finished regression. This is an environment, a place to write and run tests, not a validated test suite for an arbitrary design. A team that wants to check whether its own IP meets a specification still has to write the checks.

The third is the setup cost, and it is not a pip install. You need a RISC-V toolchain, a SystemVerilog simulator capable of running the UVM environment, Bender for the source lists, and the RTL of the core itself cloned into core-v-cores. The project directs you to external documentation for each of those, so assembling a working environment means following several guides at once.

The fourth is a project that wants a supported, versioned dependency. There is no package on a registry, no release cadence tied to the project itself, and no statement of support. The core-specific tags are the only stable points, and the project guide points to a Quick Start Guide rather than promising a maintained reference flow.

## Conclusion

core-v-verif suits a team verifying a CORE-V core that wants the same environment the OpenHW Group used rather than a bespoke one, and it suits anyone who needs to reproduce a published verification result rather than assert their own. It does not suit a project with a different core family and no interest in the CORE-V conventions, since the shared makefiles and library components assume them, and it does not suit a team wanting a ready-made regression suite for a non-CORE-V design. Before adopting it, read the Verification Strategy document and the DV plans in the docs directory, then check which core directories are actually populated, because the news entries in the archive stop at 2021 and the listed tags are cv32e40p releases from 2024 while the last push was on 2026-10-19.

## FAQ

### What is core-v-verif used for?

core-v-verif is the functional verification project for the CORE-V family of RISC-V cores. It holds the UVM testbenches for the cv32e40p, cv32e40x, cv32e40s and cva6 cores, plus the common simulation makefiles and library components they share.

### How do I get a working core-v-verif environment?

The project points first-time users to the Quick Start Guide inside the Verification Strategy document, and separately to the OpenHW Group website for background. You also need the RTL, because the core-v-cores directory is empty by design and is where you clone the design you want to verify.

### What is Bender and why does core-v-verif use it?

Bender is a dependency management tool for hardware design projects, used to define dependencies among IPs, execute unit tests and check that source files are valid input for simulation and synthesis tools. In core-v-verif it is mainly used as a submodule, and the Bender.yml manifest lists the files the parent project needs under a target for the top project.

### What licence does core-v-verif use?

The repository is licensed under the Solderpad Hardware Licence, Version 2.0, with the SPDX identifier given as Apache-2.0 WITH SHL-2.0, and the copyright line reads 2020, 2021 OpenHW Group. The terms are in the LICENSE.md file at the repository root.

### How do I reproduce a published core-v-verif result?

Use a tag rather than the master branch. The cv32e40p_v1.0.0 tag clones the v1.0.0 release of the CV32E40P core and is intended to let you reproduce the verification environment as it existed at RTL Freeze, and later tags such as cv32e40p_v1.8.3 pin the environment to a specific core version.

## Sources

- [Issues](https://github.com/openhwfoundation/core-v-verif/issues)
- [openhwfoundation/core-v-verif on GitHub](https://github.com/openhwfoundation/core-v-verif)
- [Project website](https://docs.openhwgroup.org/projects/core-v-verif/en/latest/index.html)
- [README](https://github.com/openhwfoundation/core-v-verif/blob/master/README.md)
- [Releases](https://github.com/openhwfoundation/core-v-verif/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openhwfoundation-core-v-verif