https://i-riscv.org/index.html A production-ready RVA23U64 RISC-V SoC. Every mechanism is real, verified hardware: it boots an unmodified Linux kernel out of simulation, and its cryptographic implementations pass NIST ACVP validation. i-RISCV provides a CPU implementing the RISC-V instruction set architecture (ISA) along with a large set of RISC-V extensions. Why i-RISCV Full RVA23U64 profile. RV64IMAFDCV with hypervisor (H), vector crypto (Zvk*), AIA interrupts, and IOMMU – every mechanism is real hardware verified end to end, not a teaching core. Configurable at synthesis time. Every optional mechanism – the four Zvk* crypto units, the entropy source, the branch predictor, PMP, IOPMP, the FUSE controller, and the UART – is gated by its own build-time *_ENABLE parameter: set it to 0 and the hardware is removed from the design entirely, not merely tied off. Single-core or multi-core (NUM_HARTS) is likewise a synthesis-time choice. Boots real Linux. Unmodified upstream OpenSBI plus stock, unmodified Linux v6.6 and v7.2: full extension detection, Sstc timer from S-mode, real UART console, KVM initialization. Fully tested, fully documented. Unit tests, directed assembly tests through the real pipeline, a build-permutation matrix, RISCOF conformance, differential fuzzing harness, NIST ACVP crypto validation – with complete design documentation for every mechanism. Author Stephan Mueller smueller@chronox.de Hugo en-us Fri, 02 Oct 2026 00:00:00 +0100 https://i-riscv.org/risc-v_extensions/index.html Sat, 19 Sep 2026 00:00:00 +0100 https://i-riscv.org/risc-v_extensions/index.html The following RISC-V ISA extensions are supported. The *_ENABLE column names the synthesis-time parameter that removes a mechanism from the design entirely (both simulation and real synthesis) where one exists – every such combination is verified end-to-end by verif/enable_matrix. Extension Description *_ENABLE I Base RV64I integer ISA (all 64-bit ops incl. *W 32-bit forms) – M Multiply/divide (RV64M): combinational multiply, multi-cycle restoring divide – A Atomics (RV64A): AMO* + LR/SC – F Single-precision floating point (RV64F) – D Double-precision floating point (RV64D), incl. multi-cycle FDIV/FSQRT – Zfa Additional FP ops: FLI.S/FLI.D, FMINM/FMAXM, FROUND/FROUNDNX, FCVTMOD.W.D, FLEQ/FLTQ – C Compressed (RVC): 16-bit instructions expanded to RV64 in fetch – V Vector with VLEN=512: integer/FP arithmetic, reductions, mask/permutation ops – H Hypervisor: nested virtualization, VS-level state, G-stage second-stage translation – Zicsr CSR access instructions; baseline for all CSR interfaces (incl. the entropy-source CSRs) – Zifencei Instruction-fetch fence (FENCE.I) for I-cache coherence – Zba Bitmanip: address-calculation instructions (implemented in the ALU) – Zbb Bitmanip: basic bit-manipulation instructions (implemented in the ALU) – Zbs Bitmanip: single-bit instructions (implemented in the ALU) – Zicond Branchless conditional zeroing (CZERO.EQZ/CZERO.NEZ, implemented in the ALU) – Zicbom Cache-block management: CBO.INVAL/CLEAN/FLUSH (architectural no-ops – no cache exists) – Zicboz CBO.ZERO: real multi-cycle 64-byte block write – Zihintpause PAUSE hint (decodes as a NOP on this in-order core) – Zicbop PREFETCH.R/W/I hints (decode as NOPs – no cache exists) – Zawrs Wait-for-reservation-set WRS.* (decode as immediate-return NOPs) – Zkt Data-independent execution timing for integer ops (holds by construction) – Sstc Supervisor-mode Timer Compare extension – Smaia Machine-mode AIA CSRs for the advanced interrupt architecture (APLIC/IMSIC) – Ssaia Supervisor-mode AIA CSRs – Sv39 39-bit virtual memory (3-level page tables) – Sv48 48-bit virtual memory (4-level page tables) – Sv57 57-bit virtual memory (5-level page tables) – Svade A/D bits set by software: with ADUE=0, a leaf PTE that would otherwise succeed but has A=0 (or D=0 on write/AMO) raises a genuine page fault for the OS to fix up – Svadu A/D bits set by hardware: with ADUE=1 (the reset default), the walker atomically updates a leaf PTE’s A/D bits in place – both extensions coexist, selected at runtime per translation stage – Svinval SINVAL.VMA selective invalidation with SFENCE.VMA’s exact selectivity – Svpbmt Page-based memory types via the PTE PBMT field (folded into the walker’s fault path) – Svnapot Ratified 64 KiB NAPOT page-table encoding (folded into the walker) – Zicfilp Forward-edge CFI: LPAD landing pads; a non-exempt JALR arms an expected-landing-pad state enforced on the next fetch (software-check exception, mcause=18) – Zicfiss Backward-edge CFI: dedicated shadow stack (ssp, SSPUSH/SSPOPCHK) with its own PTE encoding; a mismatched pop raises the software-check exception – Ssdbltrp/Smdbltrp Double-trap detection: per-privilege sticky trap-in-flight bits redirect an unexpected trap one level up (mcause=16, suppressed cause in mtval2); M-level halts the hart in a permanent critical-error state – Zvkb Vector crypto bit-manipulation: VANDN/VROL/VROR/VBREV8/VREV8/VWSLL – Zvkt Data-independent vector execution latency (holds by construction on the serial engine) – Zvkned Vector AES-256 block cipher ZVKNED_ENABLE Zvkg Vector AES-256-GCM/GMAC authenticated encryption ZVKG_ENABLE Zvknhb Vector SHA2-256/384/512 hash ZVKNHB_ENABLE Zvknhk Vector SHA3/Keccak (draft proposal, not yet ratified) ZVKNHK_ENABLE PMP Physical Memory Protection mechanism PMP_ENABLE Smepmp M-mode PMP enhancement: mseccfg RLB/MML/MMWP lock and write-restriction rules PMP_ENABLE IOPMP I/O Physical Memory Protection for DMA devices IOPMP_ENABLE Zkr The scalar entropy-source seed CSR (0x015, wipe-on-read, OPST status bits) on top of the hardware entropy source; access gated by mseccfg.sseed/.useed – https://i-riscv.org/cryptographic_support/index.html Sat, 19 Sep 2026 00:00:00 +0100 https://i-riscv.org/cryptographic_support/index.html The i-RISCV CPU provides a number of cryptographic support. The cryptographic implementations are tested with the NIST ACVP framework using simulation. The testing was conducted using the ACVP Parser. The algorithm implementations are standalone, reusable RTL modules which are connected to the respective RISC-V ISA extensions. Thus apart from the RISC-V ISA, the algorithms can be instantiated in separate use cases or even extracted from the RTL code to a separate project; each core also ships with a documented C API for driving it from Verilator or an external project. https://i-riscv.org/entropy_source/index.html Sat, 19 Sep 2026 00:00:00 +0100 https://i-riscv.org/entropy_source/index.html The i-RISCV provides a complete entropy source along with all tools necessary to analyze it to verify the compliance with the stochastic model. Configuration FUSES The RTL implements a FUSE controller which, however is not backed by OTP-FUSES, but with memory that is can be written to by software in RISC-V M privilege mode where the software can set a lock which makes the configuration values read-only until next reset. https://i-riscv.org/io/index.html Sun, 20 Sep 2026 00:00:00 +0100 https://i-riscv.org/io/index.html The i-RISCV SoC provides the following input/output mechanisms. IOMMU The SoC implements the RISC-V IOMMU (v1.0) for DMA-capable devices. Supported mechanisms: Device Directory Table (DDT) walk in Off, Bare, 1LVL, 2LVL, and 3LVL modes Second-stage-only DMA address translation (Sv39x4/Sv48x4/Sv57x4) with hardware A/D update on page-table entries MSI address translation, redirecting a device’s writes to a guest’s virtual IMSIC interrupt file onto the real physical guest file (AIA/IMSIC tie-in) IOATC: a device-context cache and an I/O TLB, invalidated via IODIR.INVAL_DDT and IOTINVAL.VMA/.GVMA commands Command queue (IOTINVAL, IOFENCE.C, IODIR) and fault queue for translation errors WSI (wire-signal) interrupt delivery to the PLIC/APLIC on faults or fence completion IOPMP enforcement of the final physical address after every successful translation AIA and IMSIC The core implements the RISC-V Advanced Interrupt Architecture (AIA, v1.0). Supported mechanisms: https://i-riscv.org/cpu_internals/index.html Sun, 20 Sep 2026 00:00:00 +0100 https://i-riscv.org/cpu_internals/index.html The i-RISCV core is a single-issue, in-order processor. The following mechanisms are supported. Pipeline A six-stage pipeline (IF1/IF2/ID/EX/MEM/WB) with synchronous instruction and data memory access. flowchart LR IF1["IF1<br/>PC gen"] --> IF2["IF2<br/>imem data phase"] IF2 --> ID["ID<br/>decode + reg read"] ID --> EX["EX<br/>ALU / branch resolve"] EX --> MEM["MEM<br/>dmem addr phase,<br/>CSR r/w, traps"] MEM --> WB["WB<br/>dmem data phase,<br/>regfile commit"] Supported mechanisms: https://i-riscv.org/hypervisor/index.html Sun, 20 Sep 2026 00:00:00 +0100 https://i-riscv.org/hypervisor/index.html The i-RISCV core implements the RISC-V H (Hypervisor) extension. The following mechanisms are supported. Virtualization Modes and CSRs A virtualization-mode bit V layering VS-mode and VU-mode on top of HS-mode/U-mode; SRET is the only way a hart enters a guest (hstatus.SPV/sstatus.SPP) The full hypervisor CSR set (hstatus, hedeleg/hideleg, hie/hvip/hip, hgeip/hgeie, henvcfg, hcounteren, htimedelta, htval/htinst, hgatp) and the VS-mode shadow CSRs (vsstatus, vsie/vsip, vstvec, vsscratch, vsepc, vscause, vstval, vsatp, vstimecmp) Transparent CSR substitution while V=1: supervisor CSRs redirect to their VS counterparts, including satp/vsatp and stimecmp/vstimecmp henvcfg mirrors menvcfg’s own enable fields (STCE, PBMTE, ADUE, FIOM, CBZE/CBCFE/CBIE, LPE/SSE/DTE) for VS-stage and genuinely gates VS-mode independently of menvcfg – Svpbmt/Zicbom/Zicboz access in VS-mode is gated by henvcfg’s own bit alone; only STCE and ADUE stack both levels (the guest’s effective enable is the AND), with SSE/DTE spec-forced to 0 whenever their menvcfg counterpart clears Trap Delegation and Virtual Instructions Three-way M/HS/VS trap routing via medeleg/mideleg plus the guest-level hedeleg/hideleg; VS interrupts (VSSIP/VSTIP/VSEIP) and SGEIP are always delegated at least to HS-level, and SGEIP can never be delegated further down Interrupt-cause renumbering when delegated into VS-mode, so a guest sees ordinary supervisor numbering Virtual-instruction exceptions for HS-qualified instructions blocked by V=1, covering both spec groups (VTVM/VTSR-gated and unconditional, incl. WFI under VTW) Two-Stage Address Translation Separate VS-stage and G-stage walkers/TLBs in Sv39x4/Sv48x4/Sv57x4, mirroring the single-stage modes “Walk of a walk”: every VS-stage page-table read – root pointer and each PTE – is itself G-stage translated before reaching memory Guest-page-fault causes (20/21/23) distinct from ordinary page faults, always attributed to the original access kind – including when a VS-stage PTE fetch (checked as an implicit read) fails in G-stage HS-level mstatus.MXR overrides both stages while guest vsstatus.MXR overrides only the VS stage; HS-level SUM is ignored for two-stage accesses G-stage’s own permission quirks per spec: the U bit is always checked as though in U-mode, and a cached final result is re-checked whenever the access kind or the active VMID changes Nested Virtualization A single hardware VS/G-stage context supports nested (“L2+”) virtualization through software trap-and-emulate: a guest hypervisor runs at ordinary VS-mode, and its privileged operations (e.g. hgatp writes, HFENCE.GVMA) virtual-instruction-trap to the outer hypervisor for emulation Shadow G-stage page-table merging enforces the inner hypervisor’s intended permissions on top of the outer hosting mapping; arbitrarily deep nesting by recursively re-applying the same technique, with no additional hardware Hypervisor Instructions and Guest Interrupts HLV/HSV/HLVX explicit guest-memory access that always acts as though V=1 at hstatus.SPVP, overriding MPRV – including execute-for-read substitution in both stages HFENCE.VVMA / HFENCE.GVMA TLB invalidation for the VS-stage and G-stage respectively, reusing SFENCE.VMA’s 4-case selective predicate – rs2 selects an ASID for VVMA, a single VMID for GVMA (see Tagged TLB) Guest interrupt injection via hvip, real per-guest-file MSI delivery through two IMSIC guest files (GEILEN=2) selected by hstatus.VGEIN – each with its own physical MSI region, so migrating a guest between files never moves the device’s write target – and SGEIP/SGEIE pending/enable plumbing VS-mode virtual timer: a real vstimecmp comparator (Sstc) OR’d with hvip.VSTIP, gated by the guest’s own henvcfg.STCE; accessing vstimecmp itself requires that gate stacked on top of HS-level’s menvcfg.STCE; htimedelta offsets the guest’s view of time Disclosed Simplifications Spec-legal, not silent: https://i-riscv.org/sbi/index.html Sun, 20 Sep 2026 00:00:00 +0100 https://i-riscv.org/sbi/index.html The i-RISCV SoC provides two M-mode boot-firmware paths that reach the exact same kernel image from the same device tree. The default path uses upstream OpenSBI, genuinely unmodified; the alternate path is this project’s own standalone SBI implementation. Which firmware runs is selected purely by the linux_boot Makefile target: check/image (and their 72 variants) use OpenSBI, check-sbi/image-sbi (and their 72 variants) the standalone SBI. OpenSBI (default) A pinned, unmodified upstream OpenSBI release built with PLATFORM=generic – recognized purely through OpenSBI’s own FDT drivers matching the SoC’s device tree nodes (serial@10000000, clint@2000000, plic0), with zero source customization A tiny SoC-specific M-mode prestage programs the entropy-source FUSE bank and jumps directly into OpenSBI’s fw_jump entry point – still in M-mode, no mret All standard boot setup (medeleg/mideleg, menvcfg, mcounteren, PMP) is performed by OpenSBI itself, computed from the hart’s detected extensions – including trap-safe PMP probing on builds where PMP is disabled Standalone SBI (alternate) A from-scratch M-mode firmware implementing the modern SBI v2.0 extension set: https://i-riscv.org/linux/index.html Fri, 02 Oct 2026 00:00:00 +0100 https://i-riscv.org/linux/index.html The i-RISCV SoC boots an unmodified, stock Linux kernel. Both v6.6 and v7.2 are maintained as sibling boot harnesses sharing the same RTL, both firmware paths, and one device tree – a release 2.5 years newer booting with zero RTL or firmware changes is itself a stability test, and v7.2’s extension-detection table additionally recognizes six extensions v6.6’s doesn’t (Zicond, Zfa, Zawrs, Zicbop, Zihintpause, Zkt). What Boots Unmodified upstream Linux (v6.6 and v7.2), configured for every extension this core implements Two interchangeable M-mode boot-firmware paths: unmodified upstream OpenSBI (default) or this project’s own standalone SBI – both hand off to the exact same kernel image at the same address from the same device tree (see SBI) A single generated device tree (firmware/dts/gen_soc_dts.py) advertising all ratified ISA strings plus the real UART, PLIC, APLIC, IOMMU, and IMSIC nodes – v6.6 leaves the IOMMU/IMSIC/APLIC nodes unprobed (it has no in-tree drivers for them), while v7.2 genuinely resolves all three What Works During Boot Full extension detection by the kernel itself (base ISA plus every Z/S extension its version recognizes) Sstc: the kernel writes stimecmp directly from S-mode for every tick – no SBI TIME calls at all Real serial console: the stock 8250 driver binds to the ns16550a UART (earlycon bootconsole, then ttyS0) Full boot-to-poweroff confirmed end to end: memory management, RCU, the ASID allocator, devtmpfs, IOMMU/IMSIC/APLIC driver init (v7.2), a real clocksource switch, and KVM all initialize; the non-interactive /init then dumps /proc/cpuinfo and powers off cleanly at roughly 143M-234M simulated cycles with no panic or hang Real 2-hart SMP boot on both kernel versions (CONFIG_SMP=y against the multicore top): the second hart is parked at reset and released by SBI HSM, with IPIs via CLINT MSIP and synchronous cross-hart RFENCE TLB shootdowns (see SBI) KVM: on v6.6 riscv_kvm_init() completes cleanly; on v7.2 the full KVM AIA SGEI path resolves against the real IMSIC S-file node and returns success within seconds of kernel time This project’s own IOPMP platform driver binds on both kernels Non-interactive userspace: PID 1 is a minimal POSIX-C program built against the kernel’s own vendored nolibc – it mounts devtmpfs/proc/sysfs, dumps /proc/cpuinfo to the console between fixed delimiters, and powers off; no interactive shell (an honest scope cut: one would need a full userspace cross-toolchain) The simulator polls a testbench-only DBG_EXIT register that both firmware paths write on SRST shutdown, so a completed run stops itself immediately instead of idling to its cycle ceiling – the register is dead-code-eliminated from any real synthesis Linux Boot Log + /proc/cpuinfo Output The following listing is taken from a Verilator simulation run showing the unmodified OpenSBI booting an unmodified Linux 7.2.4 kernel. https://i-riscv.org/testing/index.html Sun, 20 Sep 2026 00:00:00 +0100 https://i-riscv.org/testing/index.html The i-RISCV implementation is verified with multiple, complementary test approaches – from module-level unit tests up to booting an unmodified Linux kernel, plus a fully open-source flow that takes the same RTL to a real ECP5 bitstream. The following approaches are used. Simulation Test Layers Module-level unit tests (tb/unit/): every RTL module gets a standalone Verilator C++ harness that instantiates only that module, drives its ports directly, and self-checks against hand-computed expected values or independent reference models (e.g. an independently re-implemented RVC decoder model swept over all 49152 encodings, the host CPU’s own IEEE-754 FPU as floating-point oracle). Dedicated builds with deliberately wrong known-answer vectors prove each crypto core’s self-test failure/lockout and recovery paths. Directed full-core assembly tests (tb/tests/asm/): self-contained, hand-written RV64I+Zicsr+Zifencei programs, each exercising one pipeline mechanism end-to-end through the real SoC – single-core (check) and multi-core (check-mc). Every test reports its verdict as a P/F byte over the real UART peripheral, so the console path is exercised by every test’s own plumbing. Where a mechanism’s observable effect is timing rather than architectural state – e.g. WFI’s genuine fetch/issue stall versus a NOP-like retirement – the test measures real elapsed cycles (rdtime) around the instruction and asserts it falls inside the expected bound window, across ordinary wait-and-wake, same-cycle-NOP, and every TW/VTW/U-mode/VS/VU trap scenario. Build-parameter enable/disable matrix (verif/enable_matrix/): independently elaborated builds for every combination of the optional-mechanism *_ENABLE parameters (a 32-way Zvk*/entropy-source permutation plus separate UART and async-reseed legs – 356 runs in all), each running a general regression battery plus state-specific tests – real known-answer vectors when enabled, illegal-instruction proofs when disabled. Deliberate negative-control runs confirm the harness would actually fail if the RTL gating were broken. External NIST ACVP test-vector harness (ACVP Parser): externally supplied NIST ACVP JSON vectors reach the real RTL unmodified through a dedicated C backend – no software reimplementation of any algorithm is involved (SHA-2, SHA-3/SHAKE, AES-256, GCM/GMAC, KMAC256). The backend is compiled and linked against the real RTL today; live external-vector reconciliation is tracked follow-on work. Conformance and System-Level Testing RISCOF conformance suites (verif/riscof/): RISC-V International’s own official riscv-arch-test suites (I, M, C, D, Zifencei, privilege) run through a RISCOF-based harness with a bind-based monitor – test sources and expected signatures are both produced by RVI, independent of this project; the reference is riscv-arch-test’s own shipped .reference_output files rather than a live golden model. 275 of 283 tests pass; the 8 open privilege misalign-* cases stem from that shipped-reference limitation (this core splits misaligned accesses in hardware, while RVI’s static signatures assume trap-based behavior) and are independently verified by directed tests. Where no official suite exists (V, H, AIA, IOMMU, vector crypto), the project’s own directed tests stand in; all results and open issues are disclosed. Linux boot as a system-level test: an entirely unmodified, stock Linux kernel (v6.6 and v7.2) boots against the whole SoC through both firmware paths, on one and two harts – real, independently developed software with its own timing assumptions, catching classes of bug no directed test reaches (peripheral register-ordering hazards, firmware/CSR ordering issues, asynchronous-interrupt races). Firmware smoke tests: standalone S-mode programs (linux_boot/tools_scripts/run_sbi_smoke.sh {up,smp,dueling}) validate the boot firmware in isolation without paying for a full kernel boot – every implemented SBI extension via real ecalls on one hart; a second real hart started and IPI/fenced on two harts; and a dueling-RFENCE regression for a cross-hart fence deadlock. Differential fuzzing harness: generates randomized-but-legal RV64I+Zicsr/Zifencei instruction streams and runs the same stream through both a golden reference model of Spike and the RTL executed with the Verilator simulator, comparing full architectural state after every retired instruction: all GPRs, PC, and the CSR list. Divergences are delta-minimized into self-checking directed reproducers kept in-tree. Hazard-Family Regressions and Assertion Safety Nets Interrupt-vs-commit-race regressions: real CLINT timer interrupts phase-swept across the commit windows of every multi-cycle unit (AMO, CBO.ZERO, misaligned split stores, vector stores, cold page-table walks), with poison-value consumers and negative-control reverts proving each test genuinely discriminates Cross-hart synchronization regressions: two harts free-running unsynchronized AMO and LR/SC increment races against a shared counter (the final count must be exactly 2N), plus PLIC in-service-latch coverage – every other shared, multi-hart-reachable resource audited safe by construction SVA assertion safety net: assert property blocks checked under Verilator’s --assert in every simulation build point guard the whole hazard family; one property cross-checks an independently maintained enumeration of privilege/interrupt/translation-relevant CSR writes against the redirect-handling list, so a future edit that drops a category fires deterministically instead of waiting for a probabilistic directed test to hit its exact race cycle Side-Channel and Non-Functional Audits Constant-time (cycle-count) audits: each cryptographic core and vector-crypto unit is audited that execution latency never depends on the value of keys or data – only on public control signals – measured across different contents at fixed operation shapes; the hardware entropy source receives the same treatment. Speculative-execution resistance: a citation-backed argument (the Spectre/Meltdown disclosure papers are archived in docs/specifications/) that no mis-speculated instruction can leave an observable footprint, plus predictor-state erasure on every privilege-domain crossing – verified at unit and directed-test level. Entropy-Source Statistical Validation Stochastic-model regression (scripts/entropy/): pure-Python statistical tests of the noise-source entropy models (closed-form checks, capture-format round-trips, chi-square machinery, restart-homogeneity, worst-case min-entropy accounting). Captured-data analysis: real noise-source data – from simulation and from real silicon via the FPGA harness – is captured over UART and analyzed against the stochastic model to determine entropy rate. Compliance analysis: SP 800-90C (RBG2(P)/RBG3(RS)) and AIS 20/31 v3.0 (DRG.4+PTG.2 / PTG.3) compliance is documented requirement-by-requirement, with all disclosed gaps listed. Real-Hardware (FPGA) Testing A fully open-source flow (yosys read_slang + synth_ecp5 -> nextpnr-ecp5 -> ecppack -> openFPGALoader) targets the ULX3S (Lattice ECP5): https://i-riscv.org/about/index.html Sun, 04 Feb 2024 16:40:36 +0100 https://i-riscv.org/about/index.html Code Signing Certificate All source code distributed on this web site is signed. In order to verify the signature and thus the integrity and authenticity of the obtained code, use the following command: ​ Shell 1 gpg --verify leancrypto-*.tar.xz.asc leancrypto-*.tar.xz This command only performs the verification if the associated public key was previously imported into the key ring. In case the public key needs to be imported, use the following command which imports the key from 2024: