NEORV32: a VHDL RISC-V soft-core SoC configured by generics

One repository holds the CPU, SoC, software and tests

The NEORV32 is not a CPU core alone. What sits in the tree is a four-part package: the CPU, a microcontroller-like SoC built around it, a C software framework and a test infrastructure. 12 top-level entries make that split visible without opening anything. Hardware description lives in `rtl/`, simulation in `sim/`, the C side in sw/, and prose plus generated figures in `docs/`, with `.github/` carrying the workflow definitions that drive the build.

Intended users are named plainly: digital design and RISC-V beginners, plus experienced users, with the processor positioned as an auxiliary controller inside a larger SoC or as a small stand-alone microcontroller. That is a narrower goal than a general-purpose application processor, and the design leans into it, aiming to be as small as possible while staying as RISC-V-compliant as possible.

One administrative detail belongs with it. The project is BSD-3-Clause licensed, and the last push landed on 2026-09-27, one week after v1.13.6, which followed v1.13.5 and v1.13.4 in the six weeks before it. A 32-bit core that reached v1.13.6 within those bounds is a project on a short, dense cadence rather than one that changes shape every few years.

Generics fix the SoC before anyone writes firmware

Configuration runs through VHDL generics, and that one mechanism explains most of how the design adapts. By using generics the design is highly configurable and can be tailored to the application, with nothing decided at run time. Which CPU extensions exist, which peripherals are present and how big the memories are all get chosen when the design is elaborated for a target, then frozen into the bitstream.

That ordering matters because of where the memories end up. The design is described as technology friendly, with all internal memories mappable to FPGA or ASIC primitives, so one source tree can target a vendor block RAM on a development board and a foundry macro on a tapeout. This is the second appearance of the word primitives inside the same nine-item feature list, immediately after the claim that the design contains no primitives, macros or attributes. Both sentences sit next to each other. The first uses primitives to mean vendor-specific language constructs; the second uses it to mean the physical memory cells the generated hardware is allowed to instantiate.

Two stated goals then pull against each other: minimum size against maximum RISC-V compliance. Nothing on the page ranks them. A configuration that drops an extension gets smaller and less compliant, and which side wins is left to whoever integrates the core.

A Verilog conversion path undercuts the VHDL-only claim

Take any single line from the feature list and the project looks like a one-language effort: behavioural, platform-independent VHDL with no primitives, macros or attributes, and a topic list of 10 tags in which only 2 name a language. Read the whole page and a second language arrives anyway.

The first badge on the page points at an auto-conversion setup under `rtl/verilog` for an all-Verilog version of the processor. Continuous integration runs a Verilog Conversion task against that directory, so the generated tree is checked on every push rather than maintained by hand. That combination makes the repository a VHDL source of truth with a generated Verilog shadow beside it.

The two statements are reconcilable, since the point of behavioural VHDL is portability across tools and conversion extends that portability to toolchains that read no VHDL at all. What the page never explains is what the conversion preserves. Anyone planning to edit the generated Verilog directly gets no documentation of which constructs survive a regeneration.

Six FPGA vendors and an ASIC tapeout share one source

Portability here is tested across vendors rather than argued. Synthesis has been carried out on 6 FPGA families, AMD, Intel, Lattice, Microchip, Gowin and Cologne Chip, and the processor has been taped out several times as an ASIC. Board-specific work, including the toolchain settings each board needs, sits in the separate setups repository, which also collects community projects and keeps that glue out of the core tree.

Clock frequency is the other stated priority, and the reasoning given is integration rather than throughput: optimising for high clock frequencies eases integration and timing closure for whoever drops the core into a larger design. That is a coherent choice for an auxiliary controller, where the surrounding SoC usually fixes the clock budget. It also means the argument on the page is about timing closure, not about instructions per cycle, and no frequency figure, cycle count or area number appears anywhere to settle it either way.

Nine external destinations carry the operating systems

Self-containment has a boundary, and it is worth drawing precisely. The key features call the project fully self-contained with no external dependencies. Read that as a claim about the hardware core and it holds: the VHDL, the testbench and the C framework are all in this tree, with no vendor IP to bring in and no build-time library to fetch.

Read it as a claim about software you can actually run on the processor and it does not reach that far. The page links nine external destinations, none of them a dependency pulled in at build time. Upstream Zephyr board support and a FreeRTOS port live elsewhere. Linux runs through a separate project at `14sea/see_neorv32_run_linux`, and LiteX has its own wiki page. A MicroPython port, an Ada HAL at `GNAT-Academic-Program/neorv32-hal` and Rust support through the Embassy framework at `embassy-neorv32` follow the same pattern.

Each is an independent version stream with its own compatibility story, and nothing on the page states which core version any of them targets.

Compliance is checked from a separate repository

Five continuous integration tasks appear in the project status table, and read together they show what the maintainers treat as breakable. GitHub pages builds the documentation site, and a Documentation task rebuilds the data sheet and user guide. A Processor check runs the example at `sw/example/processor_check`. A Verilog Conversion task keeps `rtl/verilog` in step with the sources. The fifth row points outward: the RISC-V compliance badge resolves to a workflow inside the separate act repository rather than to a job here.

That placement is the detail worth noticing. Passing the official RISC-V Architectural Certification Tests is claimed, and the claim is not verified from inside the tree you would clone. The harness, its build and its result all live in a second project that has to be moved forward when the core changes, so tracking compliance history means reading two commit logs rather than one.

The self-check is arranged differently. `sw/example/processor_check` belongs to the software tree rather than the design sources, so the check ships as firmware alongside the rest of the C framework.

Reaching hello world without an install script

There is no install step, and the project does not pretend otherwise. Nothing is fetched by a package manager and nothing has to build before the design can be read. The route given is documentation first: a data sheet and a user guide, each offered as PDF and HTML, plus a Doxygen API listing for the software framework, all reachable from `https://stnolting.github.io/neorv32/`.

For an editor, the page points at a pre-configured Eclipse project, and the destination is a single call. The feature list describes the path as running from zero to a hello-world `printf`, with the whole chain open source and documented:

printf("hello world");

For hardware, the sequence the documentation sets out is: take the tree, pick the generics that match the board, synthesise for the FPGA, load the bitstream, then run the C example. Which toolchain settings a particular board wants is delegated to the exemplary setups and community projects held in the separate setups repository rather than described on the page.

Where a vendor part or a bought core fits better

The honest limits show up in what the page never states. No clock frequency, area figure, power number or cycle count appears, so the timing-closure argument has nothing behind it on the page itself. Minimum size and maximum RISC-V compliance are stated as coequal goals, with no statement of which one a given configuration favours. Where instruction throughput decides the outcome, that silence is the deciding fact.

The alternative worth comparing is not another soft-core, because no other core is named and no comparison against one exists here. The comparison the page does support is between integration routes. Taking the processor as it ships means editing generics inside VHDL in a SoC you assemble yourself. The LiteX SoC builder integration moves SoC composition out of hand-written HDL and into a builder tool, and the Vivado IP Block packaging does the same for Xilinx users by exposing the configuration through the vendor GUI. Those are two different places to hold the configuration, and nothing on the page documents how they interact with each other or with the plain VHDL path.

Where a bought core or a vendor part wins is territory the repository is silent on: an errata process, a support contract behind the toolchain, or an electrical specification already validated for the target application.

Editorial conclusion

NEORV32 suits engineers who want to own a design end to end: a 32-bit RISC-V CPU, its SoC, the C framework and the testbench in one readable VHDL tree, shaped by generics before synthesis. It suits nobody who needs a published frequency, area or power figure, or one support contract behind the toolchain. Before committing, confirm that regenerating `rtl/verilog` fits your flow, that `sw/example/processor_check` passes on your own configuration, and that the OS port you need is not three repositories behind your core version.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. stnolting/neorv32 on GitHub