How to pick a RISC-V soft core for your FPGA
"RISC-V" is not a processor, it is an instruction set, and that is the good news: dozens of open, free, silicon-proven cores speak it, from ones that tuck into a corner of the smallest FPGA to ones that boot Linux. The catch is that "just drop in a RISC-V core" hides a real decision. Pick the wrong one and you either burn three quarters of your fabric on a CPU you did not need, or you discover halfway through that your core cannot do the one thing the project required. Here is how to choose on purpose.
A soft core is a CPU built from your FPGA's ordinary logic, so it spends LUTs and block RAM you could have spent on your actual datapath. That cost is exactly why the choice is worth five minutes.
The five questions that decide it
- Do you need to run Linux? This is the biggest fork in the road. Linux wants virtual memory (an MMU), the supervisor privilege mode, and realistically atomics and compressed instructions too:
RV32IMACplus an MMU at the very least, more oftenRV64GC. If you only need bare-metal firmware or a small RTOS, you can ignore an entire heavyweight class of cores. - What is your area budget? A core that fits a tiny iCE40 and a core that fills half an Artix are both "a RISC-V", and they differ by two orders of magnitude in logic. Know your LUT and BRAM headroom before you shop.
- Which language will you live in? You will read this core, wire it up, and probably patch it. Verilog, SystemVerilog, VHDL, Chisel (Scala) and SpinalHDL are all represented, and being fluent in the source language matters more than a few percent of performance.
- How much does verification pedigree matter? A hobby blinker and a core going into a product have very different tolerances for "probably fine". Some cores carry serious industrial verification; others are brilliant but lightly tested.
- Do you want a CPU or a whole SoC? A bare core still needs memory, a bus, a UART and a debug link before it does anything useful. Some projects hand you the whole system; others hand you a CPU and a wish of luck.
A first-cut decision tree. The blue boxes are starting points, not commandments: real projects tune the ISA and the memory system after they pick a family.
The shortlist
Sizes are order-of-magnitude on a 7-series FPGA, for the core logic only (caches and program memory are on top) and swing wildly with configuration. Treat them as "which zip code", not "which house".
| Core | Typical ISA | Rough LUTs | Language | Linux? | Sweet spot |
|---|---|---|---|---|---|
| SERV | RV32I | ~200 | Verilog | no | Absolute minimum area, core arrays |
| PicoRV32 | RV32IMC | ~1k | Verilog | no | Tiny control and glue logic |
| Ibex | RV32IMC | ~2k | SystemVerilog | no | Verified bare-metal control |
| VexRiscv | RV32IMAC (+MMU) | ~0.6k to 8k | SpinalHDL | optional | Best performance per LUT, scales up |
| NEORV32 | RV32 + many | ~1.5k + peripherals | VHDL | no | A ready-made microcontroller SoC |
| Rocket | RV64GC | ~15k+ | Chisel | yes | Application-class reference core |
| CVA6 | RV64GC | ~20k+ | SystemVerilog | yes | Verified application-class |
Honourable mentions: VeeR (SweRV) from CHIPS Alliance for high-performance embedded, CV32E40P for a verified core with DSP extensions, and FemtoRV if you are learning and want a core you can read in one sitting.
Many of these live in the LibFPGA registry, so once you have chosen, lfpga add <name> pulls the verified source straight into your project.
Reading the table by use case
Smallest possible: SERV and PicoRV32. SERV is a bit-serial RV32I that is, gloriously, the world's smallest RISC-V: it processes one bit at a time, so it is slow, but it fits where nothing else will and lets you sprinkle dozens of cores across a die. PicoRV32 is the pragmatic tiny choice: a compact, high-Fmax Verilog core that trades instructions-per-cycle for area and simplicity. Both are ideal as an auxiliary brain next to real hardware.
Verified bare-metal control: Ibex. A compact two-stage RV32IMC core with genuine industrial verification behind it (it is the processor in OpenTitan). When the CPU is on a path that has to be trustworthy, pedigree beats a few extra DMIPS.
Best bang per LUT: VexRiscv. Generated from SpinalHDL through a plugin system, VexRiscv spans an enormous range from a sub-1k-LUT minimal core to a cached, MMU-equipped design that boots Linux, and it posts some of the best performance-per-area numbers on FPGA. It is the default answer for "a good general-purpose core on fabric", and it is what LiteX reaches for.
A whole microcontroller: NEORV32. If you would rather receive a working SoC than assemble one, NEORV32 is a configurable RV32 microcontroller in clean, well-documented VHDL, complete with UART, SPI, GPIO, timers and more on board. No Linux, but for embedded control it saves you a week of plumbing.
Application class and Linux: Rocket and CVA6. When you need RV64GC, an FPU, and a real operating system, Rocket (Chisel) is the Berkeley reference, and CVA6 (SystemVerilog, OpenHW verified) is the industrial-grade alternative. Both are large and pull in heavier toolchains, so reach for them only when you truly need application-class compute.
Five gotchas that bite
- The memory system dominates. A CPU is only as fast as the instructions you can feed it, and on FPGA the CPU is often the small part. Budget your block RAM deliberately: our BRAM estimator sizes it, and BRAM vs distributed RAM covers where it should live.
- Match the toolchain to your ISA string. The
gccyou build with has to agree with the extensions you enabled (-march=rv32imac -mabi=ilp32). A mismatch shows up as illegal-instruction traps at runtime, not as a compile error. - Compressed and multiply are usually free wins. The
Cextension shrinks code (and therefore instruction memory) for almost no logic, and hardwareMsaves you a slow software multiply. Enable them unless you measured a reason not to. - Budget for debug from day one. A JTAG debug module plus OpenOCD and GDB turns "it hangs" into a breakpoint. Retrofitting debug late is miserable; pick a core whose debug you understand up front.
- Do not over-spec. An MMU, an FPU and 64-bit registers are expensive and pointless for a UART state machine. Right-size the ISA to the workload and spend the reclaimed fabric on the logic only an FPGA can do.
Sensible defaults
- Tiny control or glue: PicoRV32, or SERV when area is genuinely desperate.
- General bare-metal: VexRiscv, or NEORV32 if you want the peripherals included and prefer VHDL.
- Need Linux: VexRiscv in its Linux configuration (easiest via LiteX), or Rocket / CVA6 for full RV64GC application-class.
- Needs to be bulletproof: Ibex.
If you have never dropped a CPU into fabric before, the fastest happy path is LiteX with a VexRiscv: it generates a bootable SoC with memory and a UART for your specific board, and you can swap the core variant later without rewriting your system. Turning an FPGA into a CPU that runs your own C is one of the genuinely magical moments in this field, and RISC-V made it free.