Integrating an open-source RISC-V core: a checklist

Dropping a proven open-source RISC-V core into a design is one of the fastest ways to start a real project — the cores are open, the interfaces are documented, and the toolchain is free. This is a practical checklist for doing it well: picking a core, getting the license and provenance right, understanding the core’s bus interface, wiring it into an APB subsystem, and running evidence on the result. Throughout, the core stays upstream — you integrate it and run evidence on it; you do not author it, and running evidence is not an ISA-compliance certificate or a signoff.

1. Choose a core: SERV vs Ibex

The first decision is which upstream core fits your constraints. Two popular, mature choices anchor the tradeoff:

This is an area-vs-throughput and instruction-subset choice, not a quality ranking — both are widely deployed upstream cores. Match the ISA to what your software needs (does it require multiply, or compressed instructions?) and the size to your budget.

2. License and provenance

The core is third-party IP you are shipping inside your design, so treat its origin as a first-class artifact. Record the repository and exact commit SHA, the SPDX license id (SERV is ISC, Ibex is Apache-2.0 — both permissive), and keep the upstream LICENSE with the RTL. Pinning the commit makes the integration reproducible and auditable. A small PROVENANCE.md that travels with the vendored core captures all of this. None of it turns the core into your implementation — provenance is the honest record that it is upstream.

3. Understand the bus interface

A core’s instruction/data memory ports rarely speak your SoC fabric directly. SERV uses Wishbone (cyc/stb/we/ack handshaking); Ibex exposes a simpler req/gnt/rvalid request-response port on each of its instruction and data interfaces. Neither is APB or AXI, so integration means writing or reusing a bridge that adapts the core’s native protocol to the fabric, plus an address map that places memory and peripherals. Most of the real integration effort lives in that adapter, so get its handshake and back-pressure behavior right and prove it in simulation.

4. Assemble the SoC (an APB subsystem)

A minimal SoC wraps the core with memory and a peripheral bus. A common pattern: core → bridge → an APB subsystem hosting a few memory-mapped peripherals (timer, GPIO, UART), each at a fixed address. Keep the address map explicit, give every peripheral a clean reset, and watch for any clock or reset boundary the subsystem introduces — those are exactly the structural hazards a CDC check is built to catch. ChipVerify’s visual subsystem builder assembles an APB SoC over standard bridges, which is a fast way to get a synthesizable wrapper around a core.

5. Run the evidence

With the core landed and wrapped, run evidence on the integrated RTL:

• Lint — width, latches, sensitivity, and dead logic on the landed RTL and your bridge.
• CDC — structural clock-domain-crossing analysis across the subsystem boundaries.
• Synthesis — a Yosys elaboration pass to confirm the wrapper maps to gates.
• Simulation — Verilator/Icarus runs of a program against the SoC.
• RVFI readiness and lockstep — if the core exposes RVFI, check riscv-formal readiness and consider Spike-vs-RTL lockstep — reference-model agreement for the programs you run.

All of this is pre-signoff evidence about the integrated RTL. It is not an ISA-compliance certificate, not RISCOF, and not a tapeout signoff — and the core remains upstream, not our implementation. That boundary is the point: report what the engines observe, never a certification of a third-party core.

Related reading

• RISC-V core: pre-signoff evidence — the one-action integrate-then-run-evidence flow on SERV.
• Spike-vs-RTL lockstep — what reference-model co-simulation does and doesn’t prove.
• AXI4 & AXI4-Lite protocol basics — handshaking and bridges for wiring a core into a fabric.
• Clock domain crossing — the structural hazard a multi-clock subsystem introduces.

FAQ