We build open silicon, in public.
Open RISC-V Labs is a startup building open source RISC-V cores, the verification around them, and the software and libraries that make them usable. Everything happens in the open.
Processors should not be black boxes.
The processor sits under everything a device does, yet most processor designs are sealed. You cannot read them, and the claims about them are hard to check.
RISC-V opened the instruction set. We take the next step: open implementations, open verification and open documentation, so a team can understand exactly what it is putting in its product.
Make processors as open as the software that runs on them.
One loop, always public.
- 01
Design
Write the RTL and decide the architecture in the open.
- 02
Verify
Run official test suites and reference-model checks.
- 03
Document
Write down the architecture, interfaces and bring-up.
- 04
Publish
Release source, tests and results together.
- 05
Review
Take issues and pull requests, then improve.
More than cores.
A processor is only useful with the verification, software and documentation around it. We build all of it.
Processor cores
Two core families, MIST and SIPP, with open RTL for each.
Verification
Official test suites, reference-model co-simulation and formal-interface traces.
Documentation
Architecture, configuration and bring-up guides for every core.
Software and RTOS support
Toolchain flows and a verified FreeRTOS port.
Libraries and reusable blocks
Shared building blocks and software libraries around the cores.
What open means to us.
Open source
Every line of RTL, every testbench and every script is public under the MIT licence.
Open standards
Built on RISC-V and the official compliance tests, so nothing is proprietary to us.
Open process
Issues, reviews and decisions happen where everyone can see them.
Built on the open ecosystem.
- RISC-VISA and compliance tests
- VerilatorSimulation

- GCCRISC-V compiler

- GDBDebugger
- FreeRTOSReal-time OS

- GitHubOpen collaboration
Logos are trademarks of their respective owners and are shown only to indicate the tools we build with.
How we hold ourselves to it.
- 01
Publish early
We share work in progress, not just finished results.
- 02
Show the limits
Known limitations are written down next to the features. If something has not been independently reviewed, we say so.
- 03
Make results reproducible
If we claim a result, you can rerun it from the repository.
- 04
Keep it permissive
MIT licensed, so you can use, change and ship what we build.