Run an Open-Source RISC-V Core Through Pre-Signoff Evidence

RISC-V is the easiest place to start a real evidence run: the cores are open, the toolchain is open, and the interfaces a formal checker needs are standardized. ChipVerify lets you drop in a proven upstream open-source RISC-V core and run it through the same pre-signoff engines you would run on any RTL — lint, clock domain crossing, synthesis, simulation, and the RVFI/riscv-formal readiness scaffold. This guide explains that flow and is precise about the one thing it is built to protect: the line between evidence and signoff. We integrate a core and run evidence on it; we do not author the core, and running our engines is not an ISA-compliance or foundry-signoff result.

The core: SERV (upstream, not ours)

SERV, by Olof Kindgren, is the world’s smallest RISC-V CPU — a bit-serial RV32I core under the permissive ISC license. ChipVerify vendors it at a pinned upstream commit with its full LICENSE and a PROVENANCE.md (repository, exact commit SHA, SPDX id) that travel into your project alongside the RTL. It is an upstream, third-party core — not ChipVerify’s implementation, not ISA-certified, and integrating it is never a signoff. The product value is the evidence you can run on it, in minutes, without a commercial EDA license.

One flow: integrate, then run evidence

The evidence demo makes “integrate → run evidence” a single action. It lands SERV into a fresh project, then runs the RVFI/riscv-formal readiness scaffold on the landed RTL and returns a structured summary: the project id, the verbatim readiness result, the list of engines you can now run on the project, and an honest status for Spike-vs-RTL lockstep. From there each engine runs through its own route.

What the RVFI-readiness scaffold actually checks

RVFI (the RISC-V Formal Interface) is the standard set of retire-channel signals — valid, order, instruction word, register reads/writes, program counter, trap, and memory access — that upstream riscv-formal binds its proofs to. The readiness scaffold tells you whether a project is shaped for those proofs: which RVFI signals are visible, whether a clock and reset are detectable, what the local toolchain prerequisites are (SymbiYosys, Z3, a riscv-formal checkout), and it emits a wrapper/config scaffold for the handoff. It is explicitly a readiness and scaffold check, not an ISA compliance or foundry signoff result. A compliance claim requires running the upstream riscv-formal checks against a reviewed RVFI wrapper — the scaffold gets you to that handoff, it does not stand in for it.

Lockstep: an honest “not yet”

Spike-vs-RTL lockstep compares the official RISC-V ISA simulator (Spike) against the core under test, instruction by instruction. The Spike golden trace exists in ChipVerify. What does not yet exist is the other half: an RVFI testbench harness that produces the SERV DUT retire trace to compare against it. So lockstep is reported with status planned and a reason, never as a run, never as “passing,” and never as an “equivalent” result. Surfacing it as an open follow-up rather than quietly omitting it is the point: the absence of a result is itself honest evidence, and claiming a lockstep pass we did not run would be exactly the overclaim this whole flow is designed to avoid.

Evidence, not certification — the honest line

Passing lint, CDC, synthesis, and simulation on SERV, plus a clean RVFI readiness scaffold, is real pre-signoff evidence about the integrated RTL. It is not a statement that the core is ISA-compliant, not RISCOF, and not a tapeout signoff — and the core remains upstream, not our implementation. The same boundary the rest of the platform holds applies here: we run evidence engines and report what they observe, never a certification of a third-party core. For the broader picture of how these engines fit together, see RTL verification and the tapeout readiness checklist.

Related reading

• RTL verification — how lint, simulation, synthesis, and formal fit together.
• Clock domain crossing — the structural CDC analysis you can run on the landed core.
• Yosys synthesis — the open synthesis engine behind the synth-lint evidence.
• SystemVerilog assertions — the property style RVFI proofs and smoke checks build on.