Reproducibility in open-source RISC-V HW flows

Reproducibility in open-source RISC-V HW flows Peter Kourzanov1∗

Anmol Anmol1

1 imec DSRD CSA, Kapeldreef 75, 3001 Leuven, Belgium

Abstract

arXiv:2611.04883v1 [cs.SE] 3 Nov 2026

Open-source hardware is booming. To prevent fragmentation, encourage collaboration and reuse we propose the RISC-V to join forces with Reproducible Builds communities and concentrate innovation potential where its needed most: creation of new micro-architectures, IPs and their integration into new SoCs and applications. To facilitate this goal, we chose Guix, a rigorous solution for reproducible software artefacts. We apply it to dependency management & reproducibility problems in open-source hardware and show the validity of the approach, taking CVA6 as a running example. The end result - a fully reproducible collection of packaged tests, emulation, simulation and cycle-accurate models - shows a promising workflow that could (in future) scale to support larger RISC-V community with reusable software & hardware components for next-generation platforms.

Introduction and related work Open-source hardware is booming. Repositories of openly available IPs such as OpenCores, PULP, as well as frameworks similar to Chipyard, ESP, OpenPiton, BlackParrot, OpenTitan, X-heep, next to eco-systems like SpinalHDL and Litex as well as organizations such as lowRISC, ChipsAlliance and OpenHW Group see growing adoption and contributions. While this is a positive trend, diversification is not always an improvement taken for granted. Let’s consider the (open-source) software eco-systems, which have experienced strong growth from the early days of UNIX, POSIX and the C/C++ programming languages, inspiring free implementations such as BSD, GCC and the Linux kernel and eventually enabling the rise of Linux open-source stack (i.e., LAMP) to the widespread commercial adoption. There, standardizing common design philosophies, OS A{P,B}I and PL sides of this success story have shown how effective can community be in improving the ensuing software eco-system, and of course the RISC-V community’s aim is to repeat this success story for the emerging hardware eco-systems. There’s one catch, though. The ease with which software components used to be developed and modified comes with relaxed requirements on reproducibility. The development cycles are short and are forgiving to trial-and-error methodology. For hardware development, nothing like that is true: during design, implementation and fabrication stages, every successive step is ever more resource intensive.

ily due to the lack of SoTA EDA tooling. But also: verification & fine-tuning synthesis takes time. back-end challenges of mapping circuits to competitive PDKs and interconnect structures. Back-end design takes a long time to optimize, debug and sign-off. Reuse and knowledge sharing is essential To ease verification and stimulate collaboration we propose 3 essential techniques borrowed from [1]: Dependency management, Minimalism, Early cutoff & Self tracking. By adopting these ideas for open-source hardware flows the RISC-V community can accelerate innovation and throughput, ensuring success of R&D. Front-End (Design & Verification) HDLs & Generators

RISC-V Verification & Performance Models

nMigen

Verilator

Spike

GEM5

QEMU

IR & Linting SpinalHDL

Chisel

Verible

FIRRTL

CircT

SV2V

RTL

Olympia

SAIL

Reproducible Package & Flow Managers

Mid-End Opt.

Guix

Nix

ABC Yosys FPGA Netlist

Chipyard

Place & Route FPGA Netlist

SiliconCompiler

Back-End (Implementation & Layout)

FuseSOC

Sign-off

OpenFPGA

Magic

LibreLane ASIC Netlist

Fabulous

OpenRoad

OpenLane

KLayout

Netgen

Figure 1: Plethora of open-source EDA tools & flows

Dependency management

∗Corresponding author: peter.kourzanov@imec.be

Just like software build systems, hardware flows require consistent maintenance of dependencies: every step of the flow needs to use a specific version of the tool (i.e., one from Fig.1) for reproducibility. Dependencies need to be complete and parsimonious with no noise. Determinism is essential for reproducibility, hardware flow products need determinism to scale. Engineers from across the world must be able to replicate bit-exact artefact outputs (just like reproducible SW). Static & Dynamic (i.e., computed) dependencies must be both supported by reproducible hardware flows. Although some existing frameworks such as Chipyard already use a software build tool (GNU make) to manage the hardware simulation, synthesis and mapping flows, the lack of support for dynamic dependencies in GNU make is an impediment.

RISC-V Summit Europe, Bologna, 8-12 June 2026

1

Methodology We identify several bottlenecks that need to be addressed in order for RISC-V eco-system to thrive especially in competitive advanced technology nodes: architectural issues arising when innovating microarchitecture for new SoCs. Gem5 design-space exploration full-system simulations take too long. implementation difficulties of obtaining realistic circuits for open-source micro-architectures, primar-

Early cutoff & Self-tracking During development many aspects of hardware flows need to undergo modification, including HDL source code, documentation collaterals, etc. Sometimes the build recipes themselves are modified, i.e., the hardware flow should support self-tracking. Of course, when one changes comments in the source file, the artefact does not necessarily need to be fully rebuilt, so the hardware flow should also support early cutoff.

on the following sub-flows: qemu-flow, spike-flow, vp-flow, gem5-flow and cva6-flow. Each sub-flow depends on the relevant {emu,simu}lator tool (qemu, spike, vp [5], gem5 [6] and verilated-cva6, respectively) and is responsible for running all riscv-tests and for storing the complete report in the artefact output. In our approach the entry-point package obtains access to these reports from the sub-flow dependencies and fails the build if unexpected errors are detected.

Conclusions

Minimalism The paper above defines this for build tools “executing tasks at most once per build and only if they transitively depend on inputs changed since the previous build.” [1] Precise hashing To accomplish caching, support determinism, self-tracking and early cutoff a build system may opt for a thorough application of precise hashing whereby dependencies, environment, build recipes and artefact outputs are all hashed. The hashes of products of the hardware flow serve as the evidence of build recipe’s success in mapping inputs to outputs. Cloud-readiness Last but not least, the open-source hardware flow must be readily to be deployable to the cloud, enabling multiple groups of innovators to collaborate and share products in a reproducible way. protobuf@3.21.9 hdf5@1.14.6

pybind11@2.13.6

gperftools@2.11

python-ply@3.11

tcsh@6.24.15

python-pydot@4.0.1

gem5@25.1.0.1 m4@1.4.19

dtc@1.7.2

grep@3.11

spike@1.1.0-0.591cff1

boost@1.89.0 perl@5.36.0

autoconf@2.69

python@3.12.12

spike-flow@1.0.0

diffutils@3.12

sail-riscv-flow@1.0.0

riscv-tests@2024.12.17

gmp@6.3.0

automake@1.17

gem5-flow@1.0.0

riscv-test-flows@1.0.0 qemu-flow@1.0.0

gawk@5.3.0

riscv64-elf-toolchain@14.3.0 qemu@10.2.1

libsigsegv@2.14

cva6-flow@1.0.0 vp-flow@1.0.0 glibc-utf8-locales@2.41

verilated-cva6@1.0.0 riscv-vp-plus-plus@2025.05

nlohmann-json@3.12.0

python-pytest@9.0.2

verilator@4.110

libvnc@0.9.15

make@4.4.1

git@2.54.0 cmake@4.1.3

Once Guix knows where to find the packages (in Fig.3 above, after a clone is checked-out from our github repo [guix-cva6]), standard Guix build commands initiate and manage all the aspects mentioned earlier: deterministic dependency management, early cutoff, self-tracking, minimalism and publishing/pulling available artefacts to/from other machines. The final result is an empty artefact in /gnu/store - with a precise hash - which witnesses fully reproducible verification. “Why not Nix” is a fair question, as both Guix and Nix share same heritage. While many open hardware developers are now considering Nix as a "better" package manager for hardware, we do see advantages that Guix offers: a powerful and standard recipe implementation language (Scheme), full bootstrap (improving security, certifiability) and having a great community. Future work Linking this work to more {emu,simu}lators and RTL frameworks as well as extending the approach to cover back-end flows next to verification is an obvious next step. One nice future exploration would be to link this work to [7] which could further streamline proliferation of reproducible hardware flows. Finally, deployment of this approach across sites and organizations using Guix substitute servers would provide a great boost to the speed of RISC-V adoption across both academic & industrial R&D institutions in Europe and elsewhere.

Figure 2: Guix dependency graph for riscv-test-flows

Experiment with OpenHW CVA6 To demonstrate the proposed flow - following [2] - we created a set of new Guix packages encapsulating 5 sub-flows, CVA6 and riscv-tests, reused existing Guix packages for relevant tools: Spike [3], Qemu [4] , Verilator, with the related cross-compilation toolchains and other supporting Guix packages as dependencies. $guix time-machine -C channels.scm – build -L . riscv-test-flows /gnu/store/wkxya9aqd3r2...1v46831ccn26r2-riscv-test-flows-1.0.0

Figure 3: Standardized build & test process

These packages are depicted in Fig.2 as rectangles for the standard and new customized tools for the RISCV architecture that we’re using (rv64imafdc) and as ovals for new flow-related packages. The entry-point is the riscv-test-flows which validates riscv-tests 2

References [1]

Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones. “Build systems à la carte”. In: 2.ICFP (July 2018). doi: 10. 1145/3236774. url: https://doi.org/10.1145/3236774.

[2]

Christopher Batten et al. “The Case for Using Guix to Enable Reproducible RISC-V Software and Hardware”. In: 2022. url: https : / / www . csl . cornell . edu / ~cbatten / pdfs/batten-guix-carrv2022.pdf.

[3]

Spike RISC-V ISS. url: https://shorturl.at/OOBlf.

[4]

Fabrice Bellard. “QEMU, a Fast and Portable Dynamic Translator”. In: Anaheim, CA, Apr. 2005.

[5]

Manfred Schlägl et al. “RISC-V VP++: Next Generation Open-Source Virtual Prototype”. In: 2024.

[6]

Nathan Binkert et al. “The gem5 Simulator: Version 20.0+”. In: arXiv preprint arXiv:2007.03152 (2020).

[7]

Arun Isaac. ravanan: High-reproducibility CWL runner powered by Guix. Version 0.2.0. url: https : / / git . systemreboot.net/ravanan.

RISC-V Summit Europe, Bologna, 8-12 June 2026

Related documents

• Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC#784857
• Great Expectations: Benchmarking the Real-World Performance of RVV 1.0 in HPC#783267
• RISC-V and machine learning: a survey#1034477
• RISC-V and machine learning: a survey#978423
• Porting and Benchmarking Chapel on Emerging RISC-V Hardware: an HPC Viability Study#609223