OpenTitan: a root-of-trust chip design published as one monorepo

A hardware project, and what that means for how you use it

The README is short enough to read in under a minute, which is itself informative. OpenTitan is described as an open source silicon Root of Trust project whose goal is to make the design and implementation of that component more transparent, trustworthy and secure for enterprises, platform providers and chip manufacturers. It is administered by lowRISC CIC as a collaborative project producing open IP for instantiation as a full-featured product.

Instantiation is the operative word. This is not a finished part you buy, and it is not firmware you flash onto something. The repository contains hardware, software and utilities written as part of the project, structured as a monolithic repository or monorepo so that all components live in one place. The stated reason is collaboration across the partners taking part in the project, which is the standard justification for a monorepo but here also has the effect that a chip designer, a firmware team and a verification engineer all review the same commits.

The primary language is SystemVerilog, which tells you what is at the centre of the repository. Everything else exists to build or drive that.

Licensing is the second thing to establish and it is unusually clean for hardware. Unless otherwise noted, everything in the repository is covered by the Apache License, Version 2.0, with the full text in `LICENSE`. Apache 2.0 is permissive, includes an explicit patent grant, and is what chip vendors are usually willing to adopt, so the licence choice is a real part of the project's value proposition rather than a formality.

What the monorepo tree actually contains

The repository tree reads like a hardware development environment, and it is useful to walk through because it shows the phases a chip design moves through.

`hw/` is the RTL, and `sw/` is the firmware. Around them sit the machinery: `toolchain/` for the compiler and build setup, `third_party/` which includes a Tock checkout for the embedded side, and `util/` for the Python that glues everything together.

Then the quality infrastructure, which is unusually visible for a hardware project. `rules/` holds custom lint rules, and the root configuration names them: `.svlint.toml` for SystemVerilog lint, `.svls.toml` for a SystemVerilog linter, `.clang-format` for C, `.style.yapf` and `.flake8` for Python, `.rustfmt.toml` for Rust, and `compile_flags.txt`. `quality/` is a directory in its own right. The build is Bazel, with `.bazelrc`, `MODULE.bazel` and a pinned `bazelisk.sh`.

Verification has its own top-level directory in `ci/`. That is the part worth pausing on. In hardware, the expensive failure mode is a bug discovered after tapeout, so a mature open project invests heavily in formal verification, simulation and lint. A `ci/` directory at the root signals that this investment is structural rather than occasional.

Other top-level entries explain the rest. `release/` is where packaging happens, `signing/` for firmware signing, `site/` for the web presence, `doc/` for documentation sources with a `book.toml` for mdBook, `util/` for the Python tooling, and a `CLA` file listing the contributors who have signed a contributor licence agreement. There are two package requirement files, `apt-requirements.txt` and `yum-requirements.txt`, alongside `python-requirements.txt`, which tells you the build expects a Linux package manager to be present.

Where the milestones and releases say different things

The release history contains two distinct kinds of tag, and reading them together is more informative than either alone.

The design milestones are named things like `Earlgrey-PROD.M6`, published 2024-10-17. Its notes are unusually concrete about what a production milestone means: the goal was to triage engineering change order candidates identified after the previous milestone and implement approved ones, and with M6 the physical design reached its final state for the production tapeout. The changes listed have direct silicon impact, including enabling pull-down of the IOC8 pad used for sampling a test strap at reset, and changing main SRAM scrambling back to two PRINCE cipher half rounds to relieve timing pressure. That is a real hardware tradeoff, recorded: a security margin traded for timing closure.

The other kind of tag is a development bundle. `devbundle-2026-06-02-1` is the first release of the development bundle for Earlgrey 1.0.0, and it contains FPGA bitstreams, a Verilated simulation binary, an OpenTitanTool binary, an HSMTool binary, a test ROM binary and an FPGA ROM extension binary. A newer bundle follows in August 2026.

So the current artefact you can download is a set of FPGA and simulation binaries, while the last recorded production silicon milestone is from late 2024. Both are true and they answer different questions. If you want to know what the hardware design reached, the milestone notes are the record. If you want to put something on an FPGA this month, the dev bundle is what you install.

The repository records its last push on 2026-09-23, so this is active work rather than a finished artefact left on a shelf.

The Python packaging file is a map of the verification flow

`pyproject.toml` opens with a comment that understates its role: it says explicitly that this is not actually a Python project and that `pyproject.toml` is used to manage dependencies. It sets `py-modules = []` to match. The package name is `opentitan` at version `0.0.0`, and the description is `Open-source hardware root-of-trust`.

The interesting content is the dependency list, because each entry names a stage of chip development.

requires-python = ">=3.10, <3.14"
dependencies = [
  # Keep sorted

Three pins stand out for what they reveal about the constraints. `rich==12.6.0` carries the comment that it is the maximum version compatible with Python 3.6.8, used on CentOS7 nightly regression machines, so an old pinned dependency is there to serve an old machine in continuous integration. `libclang==16.0.0` is a binding library rather than the compiler itself, which points at lint tooling that parses code rather than compiling it. `pycryptodome ~= 3.19` is the crypto library, appropriate for a secure boot chain.

Then the tools themselves. `fusesoc==2.4.5` is described in a comment as the hardware package manager and build system, so the RTL is assembled from cores as packages rather than compiled as one tree. `dvsim==1.52.0` is called the build and run tool for Design Verification flows, which is the testbench side. `peakrdl-systemrdl >= 1.0` handles SystemRDL, the register description language, and the comment `Dependencies: reggen` names the register generator that consumes it. `libesedb`-style heavy lifting is absent here because this is the host tooling, not the parsers.

A `tockloader==1.13` dependency alongside a `third_party/tock` directory confirms the Tock embedded operating system is vendored and driven from here.

The Python upper bound of 3.14 is worth noting if you build this on a recent distribution, since the ceiling is a deliberate choice rather than an accident.

Where the README stops and the book begins

The README has a documentation section that points to the project book online at opentitan.org/book/, and calls the project's documentation comprehensive across all IPs and tools. That is where the substance is.

What the README does not contain is any of it: no description of the individual hardware blocks, no register map, no interface definitions, no threat model, no build instructions, and no tool invocation examples. For a project of this size that is a defensible division of labour, since the alternative would be a README trying to summarise a hardware root of trust, but it does mean the repository page alone cannot answer a technical question.

Contribution is handled by `CONTRIBUTING.md` plus documentation on project organisation and processes in `doc/project_governance/README.md`, which is the file to read if you are thinking of sending a patch. The presence of the `CLA` file alongside `COMMITTERS` means contributions go through a contributor licence agreement, which is the normal arrangement for an open hardware project where downstream manufacturers need clear provenance.

There is also a `SECURITY.md` at the root. For hardware that is an unusual and welcome file, and it is worth reading before assuming that a silicon root of trust is a good place to report a vulnerability.

Practically, the audience this serves is narrow and identifiable. If you are designing a secure element, comparing root-of-trust implementations, a platform provider deciding what to instantiate in a chip, or a researcher who needs auditable RTL rather than a vendor black box, the repository is directly useful. If you want to run it, remember the first dev bundle contains FPGA bitstreams and a Verilated simulation binary, which is the realistic entry point today.

Editorial conclusion

OpenTitan is not a library to add to a design and not a chip you can flash. It is a reference design and a source of auditable RTL for a component that will be instantiated into someone else's product, with the Earlgrey variant already at a production tapeout milestone and packaged dev bundles for FPGA and simulation. Read it when you are evaluating root-of-trust implementations, when you want to see how a security IP is specified and verified in the open, or when you need a defensible answer about key storage that is not a vendor datasheet. Start at the documentation book rather than the README, because the README is four short sections and points there immediately. Everything else in the repository assumes you have read it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. lowRISC/opentitan on GitHub
3. Project website
4. README
5. Releases