RSD: an out-of-order RISC-V core that fits on a small FPGA

A superscalar core sized for an FPGA rather than a chip

RSD is a 32-bit RISC-V out-of-order superscalar processor core, and the sentence the README leads with is the one that explains the design. RSD is very fast due to aggressive out-of-order features, while it is very compact and can be synthesized for small FPGAs.

Those two goals pull against each other. Out-of-order execution needs a reorder buffer, a scheduler, speculation and recovery logic, and every one of those is area. Building something genuinely out-of-order that still fits on a small FPGA means making careful choices about how much speculation to keep, and the project is the record of those choices.

The feature list makes the ambition concrete. The ISA support is RV32IMF, and the core supports Zephyr applications, which is a real constraint rather than a boast, since a RTOS with its own context switching and interrupt expectations needs particular support from a soft core. On the bus side there is AXI4 support. The implementation is in SystemVerilog, it can be simulated with Modelsim, QuestaSim, Verilator and Vivado, and it can be synthesized with Synplify, Vivado and Design Compiler, with Design Compiler support described as experimental. It can run on a Xilinx Zynq board, the Avnet Zedboard, and the memory structures are FPGA optimised.

The audience is therefore people who want to study or build a real processor, not people who want a production core. This is an academic core, published alongside a paper, and its value is as a readable and simulatable example of out-of-order design.

Two fetch, six issue, sixty-four in flight

The microarchitecture section gives the numbers, and they are the clearest way to understand the machine.

There is a two fetch front end and a six issue back end pipeline, and up to 64 instructions are in flight, with those parameters described as configurable. So the front end pulls two instructions per cycle and the back end can commit six, and the window between them can hold 64 instructions. The width of that window is what makes the design out-of-order rather than merely pipelined: with 64 instructions in flight, the scheduler can look far enough ahead to find work that does not depend on what is blocking.

The scheduling machinery is described as a high-speed speculative instruction scheduler with a replay mechanism. Replay is the older and simpler way to recover from a mispredict: instead of flushing the pipeline and refetching, the machine re-executes the instructions that were speculatively issued after the branch, now with the correct answer. It costs throughput and saves area, and in a design constrained to a small FPGA that is the right side of the trade.

The memory system follows the same logic. There is speculative out-of-order load and store execution with dynamic memory disambiguation, and a non-blocking L1 data cache, so a load that misses does not stall the whole pipeline. Dynamic disambiguation means the hardware works out at run time which loads and stores might alias, rather than requiring the compiler or the source to promise they do not, which is a large ask of a general purpose software base such as Zephyr.

The build is environment variables and three make targets

The getting started section is precise about what has to be on your machine, and it is worth following exactly, because the flow depends on a handful of paths being right.

You need GNU Make, Python3 and GCC (x86-64) 6 or later, GCC (RISC-V) 7 or later, and either Verilator or Modelsim and QuestaSim or Xilinx Vitis 2019.2. The README also lists the tested environment, which is a useful sanity check and also a warning: GNU Make 4.0, Python 3.4.2, GCC 6.5.0 for x86-64, GCC 8.1.0 for RISC-V, Verilator 4.026, QuestaSim 2019.4.2 and Vitis 2019.2.

The environment is set through the scripts in Processor/Tools/SetEnv.sh. Two rules are stated plainly. RSD_ROOT must be set for running the simulation, and RSD_VERILATOR_BIN, RSD_QUESTASIM_PATH or RSD_VIVADO_BIN must be set, depending on which simulator you are using, with a wiki page on the environment variables.

Then the build itself, from Processor/Src:

make            # compile
make run        # run simulation
make kanata     # run simulation & outputs a konata log file

The other two simulators are selected by pointing make at a different makefile. For Verilator you add the Makefile.verilator.mk fragment, so the command is make -f Makefile.verilator.mk run, and for Vivado it is make -f Makefile.vivado.mk run.

One small trap is called out explicitly. If the simulation ran successfully you find kanata.log in Processor/Src, and the note is that the sub-command is kanata, not konata. The README points it out because the log file and the visualiser have slightly different names, and a reader who assumes they are the same will look for the wrong file.

Konata is how you actually see the machine

The fourth and fifth getting started steps are the ones that make this project worth building, and they are about looking rather than about passing.

A successful run leaves a kanata.log in Processor/Src, and you can see the execution pipeline of your simulation above with Konata. Konata is a pipeline visualizer, downloadable from the shioyadan repository, and the README shows an animated example of it.

That is a serious piece of tooling for a hobby-scale core, and it tells you what the project is for. A test that passes tells you the processor computed the right answer. A Konata log tells you how the out-of-order window behaved: which instructions were in flight, when a branch mispredicted, how the replay mechanism recovered, where the loads and stores sat relative to each other. For a machine whose whole point is aggressive speculation, the visualisation is the documentation.

The author of Konata is the same person who wrote the processor, Shioyadan, and the two projects are maintained together. That is worth knowing, because it means the visualisation is shaped around what the core does rather than being a general purpose tool that happens to read a log file.

The practical workflow is then to run a simulation, open the log, and step through the pipeline. The project is inviting you to look at the machine working, and the machine is the artefact.

Synthesis targets and a board, with one caveat

Beyond simulation, the README covers the hardware path in fewer words, which fits the fact that the primary workflow is simulation.

The core can be synthesized with Synplify, Vivado and Design Compiler, and the Design Compiler support is explicitly experimental. The Xilinx Zynq path is documented on a wiki page for synthesising for Linux on the board, which tells you the intended target: a soft core running a Linux distribution on an FPGA rather than an ASIC flow.

The repository layout supports the same picture. There is a Processor directory that holds the whole design and the tools, a Docs directory, CREDITS.md, and at the root the README, LICENSE and the .gitignore. The Makefile fragments for the simulators live inside Processor/Src, which is why the getting started steps all say to go to Processor/Src before running make.

The design decisions here are coherent as a set. A replay-based scheduler rather than a flush-based one, a non-blocking cache with dynamic disambiguation, AXI4 for integration, FPGA-optimised RAM structures, and a pipeline visualiser that the author also maintains. Each of those is a choice to spend area carefully, and together they are the reason a 32-bit out-of-order core can be built for a small FPGA at all.

The synthesised path is less documented than the simulated one, which is the honest state of the project. The wiki is where the board instructions live, and the README's own pointer is to that page rather than to a full hardware flow.

A paper behind it, and one tag from 2023

The repository carries a References section, and it names the paper this design comes from: An Open Source FPGA-Optimized Out-of-Order RISC-V Soft Processor, by Susumu Mashimo and others, presented at the IEEE International Conference on Field-Programmable Technology in 2019, with a pre-print linked from the University of Tokyo page.

The licence is the Apache License, Version 2.0, with the copyright held by Ryota Shioya and the RSD contributors, and CREDITS.md alongside it. The README is careful about one more thing: the implementation integrates third-party packages in accordance with the licenses presented in THIRD-PARTY-LICENSES.md. For a core that ships with a bootloader, a runtime and vendor IP, that file is the one to read before you redistribute anything.

The version history is short. There are two tags, v1.0.0 and v1.1.0, and both were published on 2023-03-28, less than a quarter of an hour apart, which suggests a single release event rather than a line of development. The last push to the repository was on 2026-10-03, so the branch is being worked on well after those tags.

That gap between the newest tag and the newest commit is the detail to keep in mind. There is no release train here, so if you want a specific, known state of the design, the tags are the only fixed points, and they are from 2023. Anyone picking this up today will be building from a branch that is newer than the version anyone has published, which is fine for a research project and a caveat for anyone planning to depend on it.

Editorial conclusion

RSD fits a student or engineer who wants to read a complete out-of-order processor rather than a simplified single issue core, and who has Verilator or a commercial simulator to run it in, since the flow is simulation-first and the documented toolchain is from 2019. It does not fit a team that needs a supported upstream core or a recent release train, because the only tags are from March 2023 even though the branch is still being worked on. Before you build it, set RSD_ROOT and the toolchain path variables exactly as the wiki describes, and read the Konata output rather than only the pass or fail result, because the pipeline behaviour is the point of the project.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. rsd-devel/rsd on GitHub