Out-of-Order Execution Explained With a Real RISC-V CPU

⏱️ Reading time: 9 min

A single developer, with no team and no funding, published a RISC-V processor that executes instructions out of order and boots a real Linux system. This is not a toy simulation. It’s a 64-bit superscalar core, written in SystemVerilog, that runs kernel 6.6.50 with BusyBox on top under Sv39 virtual memory, and that also closes timing at 500 MHz in a standard 45 nm cell library (FURSOY/fursoy-cpu). It’s a real, open source case with published metrics for understanding what out-of-order execution is and what distinguishes it from a processor that executes everything in the order the program issued it.

📑 En este artículo

1. What Is Fursoy Slice-1
2. Out-of-Order Execution and Superscalar Design: What They Mean in Practice
3. Why Out-of-Order Execution Needs Non-Blocking Memory
4. What We Tested: The Lab Found Nothing to Build
5. Fursoy Compared to Existing Resources for Learning the Linux Kernel
6. What This Means for Your Work
7. Limitations and When to Skip It
8. Frequently Asked Questions
   1. Can I run Fursoy on a real FPGA?
   2. Why is the repository’s main language C++ if the processor is written in SystemVerilog?
9. References

What Is Fursoy Slice-1

Fursoy Slice-1 (fursoy_s1_core / fursoy_s1_soc) implements the RV64IMAFDV instruction set plus the Zba, Zbb, Zicsr and Zifencei extensions: integers, multiplication, atomics, single and double precision floating point, and vectors (FURSOY/fursoy-cpu). It separates RISC-V’s three privilege levels (machine, supervisor and user), implements demand paging under Sv39, and adds cycle-by-cycle performance telemetry. All of this lives in a single-author repository: about 7 stars and 0 forks as of November 14, 2026 (FURSOY/fursoy-cpu).

Several academic projects already manage to boot Linux on custom hardware. What sets Fursoy Slice-1 apart is that it does so with an out-of-order, superscalar microarchitecture, the two techniques that separate a simple processor from a high-performance one. Understanding why that’s hard requires looking at how it implements them.

Out-of-Order Execution and Superscalar Design: What They Mean in Practice

An in-order processor executes each instruction when its turn comes, even if that means waiting for the previous one to finish. A superscalar processor fetches and decodes several instructions per cycle instead of one; Fursoy does it two at a time (fetch, decode and rename of 2 instructions per cycle), according to its own documentation (FURSOY/fursoy-cpu).

Decoding two instructions is useless if the second one has to wait for data the first hasn’t computed yet. That’s where out-of-order execution comes in: it lets later instructions move ahead while an earlier one is still waiting, as long as they don’t depend on each other. This design needs three pieces with concrete sizes in this core: a 128-entry reorder buffer (ROB) (ROB_DEPTH = 128) that keeps the original order and retires instructions in that order even though they executed in a different one; a 160-entry physical register file (PRF_SIZE = 160, with 128 free speculative entries) that separates the register names the program sees from the actual registers; and 8 checkpoints (NUM_CHECKPOINTS = 8) that allow undoing speculative work in a single cycle if a branch prediction fails (FURSOY/fursoy-cpu).

flowchart LR
  A["Fetch: 2 instructions"] --> B["Decode and rename"]
  B --> C["Issue queues: INT, MEM, FP, VEC"]
  C --> D["Out-of-order execution"]
  D --> E["128-entry ROB: in-order retire"]

Each instruction type waits its turn in a separate issue queue: 32 entries for integers, 32 for memory, its own queue for floating point (with 64 FP physical registers), and an 8-entry queue for 256-bit vectors. That separation is what lets a slow multiplication avoid blocking a simple addition whose operands are already ready.

Why Out-of-Order Execution Needs Non-Blocking Memory

Letting instructions move ahead doesn’t help much if any memory access stalls the whole core. The instruction cache (fursoy_s1_l1i) is 16 KiB organized as 64 sets with 4-way associativity, with a conservative prefetcher and 2 Miss Status Holding Registers (MSHR), and the data cache (fursoy_s1_l1d) is the same size but organized in 8 banks, with a 16-entry load queue, a 16-entry store queue and 4 MSHR, so several cache misses can stay pending at once instead of being handled one at a time (FURSOY/fursoy-cpu).

Address translation follows the same logic: a dual-ported data TLB with 64 entries across 4 ways plus an 8-entry CAM for 2 MiB or 1 GiB pages, an equivalent instruction TLB, and a hardware page table walker that can read a dirty entry directly from the L1D cache without forcing its eviction. Around the core, the SoC ties everything together with a 5-to-1 priority crossbar, 256 MiB of DRAM, a CLINT, a PLIC with 31 external sources, a 16550 UART, and a minimal custom SBI firmware. In effect, it’s a complete computer capable of running a real Linux kernel, not an isolated testbench.

What We Tested: The Lab Found Nothing to Build

We cloned the repository in an isolated sandbox to see if we could reproduce anything from the project. The result was a failure, and the failure itself is the most useful data point in this section: our lab didn’t recognize a supported build stack to run the project.

In our test on Linux 6.18.15 with git 2.39.5, we ran the clone exactly as our lab executed it:

git -c protocol.allow=never -c protocol.https.allow=always -c core.hooksPath=/dev/null clone --depth 1 --single-branch --no-tags -- https://github.com/FURSOY/fursoy-cpu /tmp/lab-runs/lab-9cg4gzej/w/repo
Cloning into '/tmp/lab-runs/lab-9cg4gzej/w/repo'...

According to our lab’s measurements, the clone took 0.906 seconds, weighed 8.9 MB and used a peak of 34.8 MB of memory. Nothing unusual so far. The next automatic step in our lab, the one that tries to detect how to install or build a project from its files, returned “no supported stack detected”. That makes sense: Fursoy isn’t a Python package or a Node binary, it’s RTL in SystemVerilog meant for hardware simulators (the project itself uses Yosys and OpenSTA for synthesis), and our build heuristics are built for conventional software, not EDA workflows.

Fursoy Compared to Existing Resources for Learning the Linux Kernel

Searching GitHub for how to learn how Linux works almost always leads to three established projects: 0xAX/linux-insides, a book in progress on the kernel’s internals with about 33,755 stars as of November 14, 2026; s-matyukevich/raspberry-pi-os, a guide to learning OS development using a Raspberry Pi, with about 13,964 stars as of the same date; and sysprog21/lkmpg, the kernel module programming guide updated for 5.0+, with about 8,646 stars (FURSOY/fursoy-cpu).

The difference isn’t popularity, it’s the level of abstraction. All three projects explain the kernel assuming the hardware underneath already exists and works: they show how Linux uses interrupts, virtual memory or modules on top of a real CPU that nobody in the tutorial built. Fursoy does the opposite: it builds the hardware first and lets Linux discover it. The Sv39 virtual memory that linux-insides explains from the kernel’s side exists, in Fursoy, on the silicon side, with a concrete TLB and page table walker, with their own size and latency.

Project	What It Teaches	Level	Stars (Nov 14, 2026)
Fursoy Slice-1	How to build an out-of-order CPU that supports Linux	Hardware (RTL, SystemVerilog)	~7
linux-insides	How the kernel works internally, layer by layer	Software (reading C code)	~33,755
raspberry-pi-os	How to write a minimal OS on existing ARM hardware	Software (bare metal on an existing SoC)	~13,964
lkmpg	How to write kernel modules	Software (kernel API)	~8,646

What This Means for Your Work

If you write backend code or performance-critical code (databases, game engines, numeric pipelines), what’s useful here isn’t running Fursoy, it’s its catalog of parameters. A 128-entry ROB means the CPU can have up to 128 unconfirmed instructions in flight, but if your code has a long dependency chain (each result depends on the previous one), that headroom is useless, because out-of-order execution needs independent instructions to move ahead, not just buffer space. That’s the same reason unrolling a loop or reordering independent calculations still produces measurable gains in hot code, even on CPUs much larger than this one.

If you work in hardware verification, FPGA design, or study computer architecture, Fursoy is a complete, readable design end to end: you can review how it handles register renaming or recovery from a failed branch prediction without paying for a commercial simulator license or fighting through millions of lines of an industrial project. You can clone it, but don’t expect any automated install lab, including ours, to know what to do with it. You’ll need Verilator or a SystemVerilog simulator installed by hand.

Limitations and When to Skip It

Fursoy is a block-by-block synthesis evaluation, not a fabricated chip: the timing report closes 500 MHz on 8 separate functional blocks (fursoy_s1_branch_unit, fursoy_s1_csr, fursoy_s1_dtlb, fursoy_s1_itlb, fursoy_s1_agu, fursoy_s1_ptw, fursoy_s1_decode and fursoy_s1_alu), not as a fully integrated core. The timing margin of an isolated block tends to shrink once it’s integrated with the rest, so 500 MHz as a complete core is not yet confirmed by that same report.

It’s also not a project for anyone looking to run Linux fast on real silicon: the source itself reports an IPC of 0.84838 and a full breakdown of the 89,861,075 simulated cycles by category (useful execution, branch recovery, memory stalls, among others) (FURSOY/fursoy-cpu), but that figure comes from a functional simulation in Verilator, not a measurement at the 500 MHz clock that the block-by-block synthesis report closes at. With 0 forks and a single author, it still lacks the peer review that larger open RISC-V cores already have. If you need a RISC-V CPU for a real product, this isn’t it. If you want to understand why designing a real CPU takes months, it’s a readable, scaled-down map of one.

Frequently Asked Questions

Can I run Fursoy on a real FPGA?

The repository documents synthesis against a 45 nm standard cell library (Nangate), not an FPGA flow. Porting it would require adapting the synthesis constraints to the chosen FPGA family, and the project doesn’t document a step for that.

Why is the repository’s main language C++ if the processor is written in SystemVerilog?

That’s common in hardware projects, where the testbench is often larger than the design it tests.

References

• FURSOY/fursoy-cpu: repository and technical documentation for the processor, GitHub stats and synthesis report.
• 0xAX/linux-insides: reference book on the internals of the Linux kernel.
• s-matyukevich/raspberry-pi-os: operating systems development guide using a Raspberry Pi.
• sysprog21/lkmpg: Linux kernel module programming guide.
• Hacker News: Show HN thread where the community discussed the project’s launch.

Featured image: Foto de Vishnu Mohanan en Unsplash

How each article is made (sources, testing and editorial criteria): How we work.