kianRiscV: open RISC-V SoC designs that boot Linux and XV6 on real silicon

What the KianV family of SoCs is actually for

kianRiscV is a hardware project rather than a library, and it is aimed at people who want a whole system-on-chip, not just a processor. The repository description calls it a "RISC-V XV6/Linux SoC" with march identifiers 0x2b and 0x34, and the topic tags fill in the rest: riscv, rv32ima, sv32, mmu, soc, fpga, asic, tinytapeout, x11, xv6.

Two operating systems sit side by side in that list, and the choice between them is the real design decision. XV6 is a small teaching kernel that a reader can hold in their head, which makes it a workable target for someone learning how an SoC behaves. Mainline Linux is the harder target and the more useful one, because it forces the design to carry a real MMU, a real privilege model and a real boot flow. The README's headline design is the harder of the two: "KianV SV32 (MMU) RV32IMA Zicntr Zicsr Zifencei SSTC Linux/XV6 SoC".

The audience is a hardware engineer, a FPGA hobbyist or a student who wants to see a working RISC-V system rather than read about one, plus a small group of open-hardware regulars who follow the fabrication side. The repository is not packaged for application developers, and nothing in it is aimed at people who want to call a library.

How the SV32 Linux SoC is laid out in the repository

The top level of the repository is mostly documentation and imagery. Alongside README.md and LICENSE.md sit a set of PNG and JPEG files, including kianv_soc_core_bus.png and chip_top_white.png, plus a logos/ directory and a .gitmodules file.

That last file is the most informative entry in the listing, because it tells you the design pulls in external submodules. In a project like this, the things that arrive as submodules are normally the tool flows and process design kit, not the RTL, and the README backs that up by naming skywater130 as the PDK and pointing at wafer.space for fabrication.

The actual hardware lives in two directories. linux_socs/ holds the SoC variants, including the path linked in the README as linux_socs/kianv_mc_rv32ima_sv32, and a second one at linux_socs/LinuxSoC_v2, described as a reworked version of the Linux SoC. The README is explicit that the reworked one is "simpler, derived from my new full custom ASIC", which is a useful architectural statement: the silicon-oriented design informed the FPGA and Linux-capable design, not the other way round.

An asic/ directory sits alongside linux_socs/, and the ASIC versions of the design live in a separate repository, splinedrive/gf180mcu-kianv-rv32ima-sv32, which the README links as the GF180MCU build for the wafer.space shuttle run. So the repository holds the RTL for several SoC flavours plus the documentation, and points outward for the tapeout-specific pieces. That split is a reasonable structure for a solo open-hardware project, and it also means the flow of any given design is spread across two repositories rather than contained in one.

Getting the design and building it: what the README leaves out

There are no installation steps in the README for this project, and no build instructions either. Nothing describes a clone command, a toolchain version, a synthesis script, a simulation command or a bitstream target. The README points at the design paths and at the fabrication and community links, and stops there.

So the honest description of the workflow is: the RTL is in the repository, the surrounding flow is implied rather than written down, and the person doing the build has to supply the parts the README does not name. A minimal starting point is to fetch the tree and make sure the submodules come with it, since the .gitmodules file signals that something in the build is expected from outside the repository:

git clone https://github.com/splinedrive/kianRiscV.git
cd kianRiscV
git submodule update --init --recursive

Beyond that, the repository structure gives the map a builder would need:

linux_socs/
  kianv_mc_rv32ima_sv32/
  LinuxSoC_v2/
asic/

Two paths stand out for a first experiment. LinuxSoC_v2 is the one the README calls simpler and reworked, which makes it the lower-risk starting point for a FPGA bring-up. The SV32 MMU variant is the one that boots mainline Linux, and it is the more demanding target because it needs a working MMU, a proper supervisor-mode entry and a boot protocol the kernel can talk.

The gap is worth naming plainly. For a project that claims a full Linux boot on silicon, the absence of a documented flow means the knowledge lives with the author, in the linked talks and in the community channels rather than in the repository. That is a real adoption cost even though it says nothing about the quality of the design.

RV32IMA plus Zicntr, Zicsr, Zifencei and SSTC: reading the ISA line

The extension list in the README is the most information-dense line in it, and it is worth reading as a requirements statement rather than a feature list.

RV32IMA is the baseline: 32-bit integer, multiply and divide, and the A extension for atomics. Atomics matter for a Linux target, because the kernel expects atomic memory operations to exist.

Zicntr and Zicsr are the counter and CSR access extensions. They are what let the runtime read the cycle and time counters and manipulate control and status registers, which userland tools and performance monitoring depend on. Zifencei adds instruction-fetch fences, needed when code and data share memory and the pipeline has to be told to refetch.

SSTC is the less familiar entry. It is the supervisor-level timer interrupt extension, which lets a supervisor-mode timer interrupt a process without trapping through machine mode. For a Linux system, that removes a source of expensive trap-and-forward round trips on timer ticks, and it is a sensible thing to include in a design that targets a real kernel.

SV32 is the MMU profile: a 32-bit physical address space with a 32-bit virtual address space, page tables, and a page-table format that differs from the 64-bit Sv39 and Sv48 schemes. It is the practical choice for a 32-bit Linux port, and it is the reason the memory-management logic in the design is not simply a copy of the 64-bit paths.

The topic tags also list x11, which points to a graphics-oriented configuration somewhere in the family. The README does not describe that path in detail, so it is better treated as a lead than a documented feature.

From RTL to silicon: the wafer.space GF180MCU route

The most distinctive claim in the README is not about Linux at all. It is that KianV demonstrates an end-to-end workflow in practice: open-source RTL, open-source EDA and PDK, TinyTapeout fabrication, and a mainline uLinux boot on real silicon.

The pieces fit together into a coherent story. The PDK is skywater130, an open process design kit, which pairs with the open-source EDA tools that the TinyTapeout shuttle run makes available. The design itself is offered as a full-custom RISC-V Linux SoC, and the separate repository splinedrive/gf180mcu-kianv-rv32ima-sv32 holds the GF180MCU-specific version for the wafer.space shuttle run. The image in the README captioned as a KianV uLinux ASIC SoC is presented as the result of that run.

The README also records external recognition: at the Linux Plumbers Conference 2025 in Tokyo, D. Jeff Dionne highlighted the emergence of fully open-source silicon platforms that return from fabrication and boot mainline noMMU Linux, calling the capability "incredibly powerful". The README places KianV inside that movement, and links a FOSSI Foundation blog post about a RISC-V uLinux ASIC.

The significance is the closed loop. A design that boots mainline Linux on hardware that came back from a shuttle run has passed the test that separates a paper SoC from a working one, because a kernel that boots has exercised the memory map, the privilege transitions, the timer interrupts and the boot protocol together. That is a much stronger signal than a simulation log, and the README's framing, in which the whole chain from RTL to silicon is open, is what makes the claim checkable by others rather than self-reported.

Where KianRiscV is the wrong tool

The first limitation is the one the README does not mention: there is no build. No synthesis scripts, no simulator invocation, no constraint files, no bitstream targets, no FPGA board named anywhere in the README. For a reader who expects to clone a repository and have something running, this project cannot deliver that, and no amount of care in the prose changes it.

The second limitation is scale of adoption. This is a design maintained by one author, in a personal style, with the ASIC versions split across a second repository. There is no issue tracker policy, no test suite, no CI, and no compatibility commitment. A design that boots Linux on one tapeout says a great deal about the author's skill and very little about whether a newcomer can reproduce it on their own board.

Third, the ISA choices narrow the audience in a specific way. RV32IMA with SV32 is a 32-bit design. It suits teaching, small embedded systems and FPGA work, and it suits Linux because mainline Linux supports 32-bit RISC-V, but it is not a path to 64-bit compute, and the march identifiers in the description suggest a second configuration rather than a documented migration path between them.

The alternative to writing an SoC is not to write one. The other approach is to take a general-purpose RISC-V core and put your own peripherals, memory and interconnect around it, which trades a ready-made system for control over the bus and the device tree you care about, at the cost of writing the glue. For a Linux-capable SoC specifically, the other axis is the operating system: XV6 runs on much simpler hardware and can be understood end to end in a way mainline Linux cannot, so a project that only needs a small system is better served by the kernel that was written to be read than by the one that was written to be shipped. A team that needs a working product with support obligations is looking at a commercial core or a vendor BSP, not at a solo open-hardware design, and the difference in approach there is contractual rather than technical.

Maintenance state, licensing and the cost of adopting a solo hardware design

The repository is not archived, the last push was on 2026-05-29, and the one published release is v2.0 from 2026-01-15. A single tagged release across the life of the project is a signal in itself: this code is versioned by the main branch, and the design variants are distinguished by directory, as the LinuxSoC_v2 naming makes clear, rather than by tags.

That has consequences for anyone building on it. There is no upgrade path to plan, because there is no version sequence; you either take the current main branch or a specific commit and pin it yourself. Since the Linux and ASIC variants live in different directories and the ASIC parts live in a second repository, an update to one does not update the other, and the branches of the design can drift apart in ways the release list will not tell you about.

The licence is ISC, which is a permissive licence with a short notice requirement and no copyleft obligation on distributed derivatives. From a licensing standpoint, that is about as permissive as an open hardware project gets, and it is notably lighter than the obligations a GPL-style licence would impose on an FPGA bitstream you distribute. That part is straightforward. What the licence cannot do is stand in for the parts the repository leaves undocumented.

The realistic cost of adopting this project is an engineering day or more of reading Verilog and SystemVerilog to understand the bus, the memory map and the boot flow, plus whatever it takes to reconstruct a build around a flow the author has not written down. In exchange you get a rare thing: a complete, open, Linux-capable RISC-V system that has been through fabrication, with the RTL open enough to study and change.

Editorial conclusion

kianRiscV is worth the time for someone who wants a complete RISC-V system rather than a CPU core: it shows what a memory-mapped Linux SoC looks like in SystemVerilog and how far the same design can be carried into a taped-out chip. It is not a turnkey project for a team that expects a documented build, a synthesised netlist or a board bring-up guide, because none of that is in the repository. Verify first that the SV32 variant you plan to use matches the march identifier your bootloader expects, that the submodules referenced by .gitmodules are reachable in your environment, and that the ISA extensions listed in the README, Zicntr, Zicsr, Zifencei and SSTC, are supported by the tools you plan to use.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. splinedrive/kianRiscV on GitHub