FPGA Guide
Topic hub

Soft processors

What a soft processor is, how MicroBlaze V, Nios V, VexRiscv, NEORV32, PicoRV32 and Ibex compare, how LiteX builds a whole SoC around one, and when a soft core beats a hard one.

Updated 13 Nov 2026 · soft processor, MicroBlaze V, Nios V, VexRiscv, NEORV32, Ibex, LiteX, RISC-V

Overview

A soft processor is a CPU built from the FPGA’s own logic cells rather than hardened on the die. It costs a few thousand LUTs, runs at a modest clock, and can be placed on any device from any vendor. This hub is for engineers deciding whether to put a processor into a design, which one, and how to build the bus, memory and peripherals around it.

The reason to want one is that control logic is cheaper to write in C than in RTL. A state machine that handles a configuration protocol, a boot sequence, a calibration routine or a slow housekeeping task becomes a few hundred lines of firmware instead of a tangle of states. The reason to be careful is that a soft core is slow compared with a hard Arm core and uses resources you may need elsewhere.

Key ideas

What a soft core is made of

The core itself is a pipeline of three to seven stages that fetches instructions from a memory, decodes them, executes them in an ALU, and writes results back. Around it sit instruction and data memories built from block RAM, optionally caches, and a bus (Wishbone, AXI or the vendor’s own) connecting to peripherals: a UART, timers, GPIO, SPI, and whatever custom registers your design needs. The vendor cores come with a tool that assembles all of this from a menu. The open-source cores often come with a generator that does the same, and LiteX is the most complete of those.

RISC-V corefetch, decode, execute,memory, writeback2k to 10k LUTsInstruction RAMblock RAM, preloadedby the bitstreamData RAMblock RAM, or aDDR controller via cacheSystem bus: Wishbone, AXI4-Lite or vendor busUARTTimer, GPIOSPI flashYour logiccontrol and status registers
A minimal soft-processor system. The core, its memories and the peripherals share a bus, and custom logic appears to firmware as memory-mapped registers.

The cores worth knowing

The vendor cores have moved to RISC-V. AMD’s MicroBlaze V replaces the proprietary MicroBlaze instruction set with RV32 and keeps the Vivado block-design integration and Vitis debug flow. Altera’s Nios V does the same for Nios II inside Platform Designer. Both are free to use on their own devices and both come with the vendor’s debugger and board support. Their portability to other vendors is nil, which is the point of the open-source alternatives.

VexRiscv, written in SpinalHDL, is a highly configurable in-order core that reaches a few hundred megahertz on modern fabric and can be built with caches, an MMU and Linux support. It is the default CPU in LiteX. NEORV32 is a VHDL core with a complete SoC, excellent documentation and a focus on being small and auditable, which suits teams that must review every line. PicoRV32 is deliberately tiny and slow, suitable when the processor is a convenience rather than a performance feature, and it is the core used in many Lattice iCE40 projects. Ibex, from lowRISC, is a two-stage RV32 core with a production-quality verification environment and is the core inside OpenTitan. Rocket and CVA6 are larger application-class cores that are more often prototyped on an FPGA than deployed on one.

LiteX and SoC generators

LiteX is a Python framework that assembles a core, memory controller, Ethernet, PCIe, SATA and dozens of peripherals into an SoC, generates the Verilog, writes the BIOS and the firmware headers, and drives the vendor or open-source toolchain. It supports VexRiscv, NEORV32, PicoRV32, Ibex, Rocket and several others as plug-in CPUs. A LiteX SoC with DDR and Ethernet on an inexpensive board, booting Linux through VexRiscv, is a realistic weekend project. The cost is a Python dependency chain and a design that is harder to inspect in the vendor’s GUI.

When soft beats hard

A hard core in an SoC FPGA is faster, cheaper per instruction and runs a stock Linux. Choose a soft core when the device has no hard core, when you need several small processors next to the logic they control, when the firmware must be certified alongside the hardware, when you want the design to move between vendors, or when a design must survive the vendor discontinuing a part. Choose a hard core when you need Linux, networking stacks or real compute. Many designs have both.

Where to start

Intermediate lessons on a first NEORV32 system, a MicroBlaze V block design and a LiteX build are coming.

Tools and vendors

Core ISA Language Size (approximate) Vendor lock Debug
MicroBlaze V RV32I with options Netlist (AMD) 2k to 6k LUTs AMD only Vitis, XSDB
Nios V RV32I with options Netlist (Altera) 2k to 5k ALMs Altera only Ashling RiscFree
VexRiscv RV32IMAFC options SpinalHDL 1k to 5k LUTs None OpenOCD, LiteX BIOS
NEORV32 RV32IMC and more VHDL 2k to 6k LUTs None On-chip debugger, OpenOCD
PicoRV32 RV32IMC Verilog Under 2k LUTs None Minimal
Ibex RV32IMC, bit-manip SystemVerilog 2k to 4k LUTs None RISC-V debug module
LiteX Framework Python (Migen) Depends on CPU None LiteScope, BIOS

Sizes vary widely with configuration, caches and multiplier options. Vendor notes are at /vendors/amd/, /vendors/altera/ and /vendors/opensource/.

Common mistakes

  • Putting a soft core in because “it needs some control” and then doing performance-critical work in firmware.
  • Forgetting that the instruction memory is initialised by the bitstream, so a firmware change means a rebuild unless you add a bootloader.
  • Running the core at the fabric’s maximum clock and spending days on timing closure, when half the speed would have done.
  • Using the vendor core on a design that must later move to another vendor.
  • Skipping the debug module to save area, then having no way to see why firmware hangs.
  • Ignoring the interrupt latency of a core with a long pipeline and slow bus.

Going deeper

Recent papers

  • A State Augmented Approach to Paralle Modeling in High-Level Synthesis

    N. Kovacs, H. Zheng · arXiv cs.AR · digest

    HLS can only schedule the concurrency its input makes legal, and a plain sequential C++ model of a feedback-coupled design such as a processor hides the state boundaries the tool needs. The authors model the design as synchronous sequential processes that start together and synchronise on completion, keeping persistent state and feedback explicit in C++ while HLS schedules the operations inside each process. A five-stage RV32I core written this way reaches 1.221 cycles per instruction at 220 MHz on a Kintex UltraScale+, against 4.000 for a naive HLS version and 1.575 at 242 MHz for the hand-written Ibex core. An area-tuned variant cuts LUTs by 65 per cent at the cost of 9.7 per cent more cycles. The result depends on the designer taking back control of architecture, which is the opposite of what HLS marketing promises.