The RISC-V Ecosystem: Toolchains, Open-Source Cores, and Production Silicon

The architectural case for RISC-V rests on modularity: a clean base integer instruction set surrounded by optional standard extensions. However, an ISA is only a specification document. Its real-world utility depends entirely on the tools, simulation environments, verification collateral, firmware layers, and physical silicon that exist around it.

An engineering team selecting an architecture must answer practical questions: Can standard compilers generate optimized code for custom extension subsets? How do you verify an RTL implementation against a golden architectural reference before tapeout? Which open-source cores are production-ready for deeply embedded control versus Linux application processors? And what physical silicon can you buy off the shelf today?

This post details the operational reality of the RISC-V ecosystem across software toolchains, reference simulators, open-source RTL microarchitectures, verification frameworks, and commercial silicon products.

Software Toolchains and Compilers

The software stack begins with the compiler toolchain. RISC-V enjoys upstream support in both the GNU toolchain (GCC and Binutils) and LLVM/Clang, meaning developers rarely need vendor-patched forks for standard architectures.

+-----------------------------------------------------------------------------------+
|                        RISC-V Compilation and Binary Toolchain                    |
+-----------------------------------------------------------------------------------+
|  [ C / C++ Source ] ---> Clang / LLVM  OR  GNU GCC                                |
|                                 |                                                 |
|                                 v  -march=rv32im_zicsr -mabi=ilp32                |
|  [ Assembly ]       ---> GNU as / LLVM MC Assembler                              |
|                                 |                                                 |
|                                 v  Relocations (R_RISCV_CALL, R_RISCV_HI20, etc.) |
|  [ Linker Script ]  ---> GNU ld / LLVM lld                                        |
|                                 |                                                 |
|                                 v  Linker Relaxation (GP relaxation, C-ext relax) |
|  [ Output ELF ]     ---> objcopy / Binutils ---> Memory Hex Image / Raw Binary    |
+-----------------------------------------------------------------------------------+

GCC and LLVM Toolchain Triplet Conventions

RISC-V cross-compilers use standard target triplets that define the architecture width, operating environment, and C library target:

• riscv32-unknown-elf: Bare-metal 32-bit cross-compiler linking against newlib or freestanding runtimes.
• riscv64-unknown-elf: Bare-metal 64-bit cross-compiler for embedded systems and M-mode firmware.
• riscv64-linux-gnu: 64-bit compiler targeting the Linux kernel and userspace applications linking against glibc or musl.

Architecture Strings and ABI Conventions

Compiling RISC-V software requires configuring two independent command-line flags: the architecture string (-march) and the Application Binary Interface (-mabi).

The -march flag specifies which instruction set extensions the compiler may emit. Modern toolchains require extensions to follow standard naming rules, placing standard single-letter extensions first, followed by multi-letter Z* extensions:

# RV32 bare-metal with multiply and CSR operations
riscv32-unknown-elf-gcc -march=rv32im_zicsr -mabi=ilp32 -O2 -c main.c

# RV64 Linux application with vector support
riscv64-linux-gnu-gcc -march=rv64gcv -mabi=lp64d -O3 -o app main.c

The -mabi flag controls how arguments and return values are passed through registers versus the stack:

Multi-lib Configurations

Because the ISA is modular, a precompiled C runtime library built for rv32i cannot execute hardware multiply instructions, while a library built for rv32imfd cannot run on an integer-only core.

To solve this, toolchains rely on multi-lib builds. A single cross-compiler installation contains multiple parallel builds of libc.a, libm.a, and libgcc.a, each compiled for a specific -march/-mabi tuple. During linking, the driver automatically selects the directory matching the user’s compilation flags.

Linker Relaxation

RISC-V instruction sequences frequently use two instructions to construct 32-bit addresses: lui (load upper immediate) loads the upper 20 bits into a register, and addi or load/store offsets supply the lower 12 bits.

The GNU and LLVM linkers implement linker relaxation:

• When a target symbol falls within +/- 2 KiB of the global pointer register (gp), the linker replaces the two-instruction lui/addi sequence with a single gp-relative load or store.
• When compressed instruction support (-march=*c*) is enabled, the linker shrinks 32-bit jump and call instructions to 16-bit compressed encodings (c.j, c.jal, c.jr) when the jump target is within reach, deleting the redundant bytes and packing code density tighter at link time.

Instruction Set Simulators and Emulation

Before running code on FPGA prototypes or physical silicon, developers rely on instruction set simulators (ISS) and emulator environments.

+-----------------------------------------------------------------------------------+
|                         Simulation and Modeling Hierarchy                         |
+-----------------------------------------------------------------------------------+
|  [ Specification Layer ]  SAIL RISC-V (Definitive Formal Mathematical Model)      |
|                                 |                                                 |
|  [ Golden Functional ISS ] Spike (riscv-isa-sim, Interactive Debugger, HTIF)      |
|                                 |                                                 |
|  [ System & Platform VM ] QEMU (Full-System Linux Emulation, VirtIO, OpenSBI)    |
|                                 |                                                 |
|  [ Multi-Node Virtualization ] Renode (Heterogeneous SoCs, Sensor Bus Emulation)  |
|                                 |                                                 |
|  [ Cycle-Accurate Hardware ]   Verilator (C++ Cycle Model) / FPGA Synthesized RTL |
+-----------------------------------------------------------------------------------+

Spike (riscv-isa-sim)

Spike is the golden reference functional simulator maintained by RISC-V International. It implements the unprivileged and privileged specifications directly and serves as the baseline against which microarchitectures are compared.

Key operational characteristics:

• Runs at 20 to 50 MIPS, making it fast enough to boot Linux or execute large benchmark suites.
• Supports the Host-Target Interface (HTIF) for lightweight terminal console output and return code extraction without full peripheral emulation.
• Provides cycle-by-cycle instruction commit logging (spike -d --log-commits) to cross-check architectural register state against Verilog simulation traces.

SAIL RISC-V

SAIL is a domain-specific formal specification language developed at the University of Cambridge. The Sail RISC-V model is the official formal definition of the RISC-V architecture adopted by the technical steering committee.

Key attributes:

• Generates executable C and OCaml simulators directly from mathematical operational semantics.
• Generates theorem-prover definitions for Isabelle/HOL, Coq, and HOL4 for formal verification proofs.
• Serves as the golden reference oracle for architectural compliance test generation.

QEMU (Quick Emulator)

QEMU provides fast functional emulation for software development without requiring cycle accuracy. It operates in two distinct modes:

• User Mode (qemu-riscv64 / qemu-riscv32): Executes single RISC-V Linux ELF binaries directly on an x86 or ARM host by intercepting RISC-V system calls and translating them into host kernel calls. This enables cross-compilation testing and CI builds without booting a guest operating system.
• System Mode (qemu-system-riscv64): Fully emulates a complete virtual hardware board (such as the standard virt machine model), including the SiFive CLINT, PLIC, NS16550A UART, VirtIO storage, network adapters, and PCI buses. It boots OpenSBI, U-Boot, and standard Linux kernel distributions out of the box.

# Booting a complete 64-bit RISC-V Linux kernel inside QEMU
qemu-system-riscv64 \
    -M virt -m 2G -smp 4 \
    -bios default \
    -kernel Image \
    -initrd rootfs.cpio \
    -append "console=ttyS0 root=/dev/ram rdinit=/sbin/init" \
    -nographic

Renode

Developed by Antmicro, Renode is an open-source simulation framework that models complete multi-node networked embedded systems. Unlike pure CPU simulators, Renode models hardware peripherals (SPI, I2C, CAN, Ethernet, BLE controllers), interconnects, and physical multi-board deployments, enabling firmware validation for RTOS platforms such as Zephyr and FreeRTOS.

Open-Source RTL Microarchitectures

The open-source hardware community has produced dozens of processor cores spanning from single-LUT FPGA soft cores up to multi-core superscalar out-of-order application processors.

+-----------------------------------------------------------------------------------+
|                    Open-Source Core Hierarchy by Complexity                       |
+-----------------------------------------------------------------------------------+
|  [ Embedded / Control ]  SERV (1-bit serial) | PicoRV32 | Ibex | CV32E40P | NEORV32 |
|                                                                                   |
|  [ Mid-Range In-Order ]  Rocket Chip (5/6-stage) | VexRiscv (SpinalHDL Plugin)     |
|                                                                                   |
|  [ High-Perf OoO ]       BOOM (SonicBOOM) | XuanTie OpenC910 | XiangShan Nanhu    |
+-----------------------------------------------------------------------------------+

Microcontroller and Embedded Control Tier

These cores target minimal area, low power consumption, and deterministic interrupt latency, replacing proprietary ARM Cortex-M0/M3/M4 cores in SoCs and FPGAs:

• Ibex (formerly Zero-riscy): Maintained by lowRISC and originally developed at ETH Zurich. Written in SystemVerilog, it implements a 2-stage in-order pipeline with support for RV32IMC or RV32EMC. It features physical memory protection (PMP), extensive fault injection hardening, and is deployed as the security processor core inside Google OpenTitan silicon.
• PicoRV32: Created by Claire Wolf. A microcoded RV32IMC core designed for minimal FPGA resource utilization. It executes instructions across multiple clock cycles per instruction (typically 3 to 4 CPI) but occupies as few as 750 LUTs on a Xilinx 7-series FPGA.
• CV32E40P (OpenHW Group / PULP): A 4-stage in-order pipeline implementing RV32IMFC. Originally known as RI5CY, it features optional custom hardware loops, post-increment load/store operations, and SIMD ALU instructions tailored for edge DSP workloads.
• NEORV32: Authored by Stephan Nolting. A clean, fully synthesizable VHDL implementation of RV32I[MCB] with an extensive suite of built-in peripherals (UART, SPI, TWI, PWM, timers, TRNG, CRC, internal memories) designed for straightforward deployment on any FPGA family.

Mid-Range Pipelined Tier

Cores in this tier achieve higher IPC (0.8 to 1.4) through single-issue or dual-issue pipelining, branch prediction, and optional cache hierarchies:

• Rocket Chip: Developed at UC Berkeley. Written in Chisel, Rocket is a 5-stage or 6-stage in-order scalar core generator supporting RV32GC or RV64GC. It includes an MMU supporting Sv39 virtual memory, non-blocking L1 caches, and TileLink interconnects. It has taped out in physical silicon dozens of times across multiple commercial process nodes.
• VexRiscv: Authored by Charles Papon. Written in SpinalHDL, VexRiscv is a modular, plugin-driven 5-stage pipeline. The developer can toggle features (branch prediction, dynamic bypasses, hardware divide, MMU, CSRs) as software plugins. It achieves exceptional FPGA resource efficiency and clock frequencies exceeding 200 MHz on Xilinx Artix-7.
• SERV: Created by Olof Kindgren. SERV is the world’s smallest RISC-V core. It uses a bit-serial architecture, processing data one bit per clock cycle over 32 cycles. It consumes only ~125 LUTs on a Lattice iCE40 FPGA, making it ideal as a housekeeping controller.

High-Performance Out-of-Order Tier

These designs target server, edge compute, and application processor workloads, competing directly with high-performance commercial cores:

• BOOM (Berkeley Out-of-Order Machine): A synthesizable out-of-order superscalar RV64GC core written in Chisel. It implements a 7-stage to 10-stage pipeline with register renaming, explicit issue queues, a reorder buffer (ROB), and speculative execution. Configurations range from 2-wide to 4-wide issue (SonicBOOM), achieving over 3.8 CoreMark/MHz.
• XiangShan: Developed by the Institute of Computing Technology at the Chinese Academy of Sciences (CAS). An open-source, high-performance out-of-order RV64GCBK core written in Chisel. The second-generation architecture (Nanhu) is a 6-issue out-of-order core achieving over 10 SPEC CPU2006 / GHz, fabricated at 14nm. The third-generation core (Kunminghu) targets high-end server-class performance.
• XuanTie OpenC910: Open-sourced by Alibaba T-Head. A commercial-grade 12-stage out-of-order RV64GCV core supporting dual-issue to triple-issue decode, vector extension support, hardware cache coherency, and multi-core SMP clustering.

Open-Source RTL Core Comparison

Architecture Verification and Compliance Frameworks

Because the ISA allows endless combinations of extensions and microarchitectural choices, rigorous verification frameworks are mandatory to ensure that an implementation correctly executes instructions according to the specification.

+-----------------------------------------------------------------------------------+
|                        Verification Ecosystem Architecture                        |
+-----------------------------------------------------------------------------------+
|  [ Compliance Suites ]    riscv-arch-test (Formal architectural test vectors)     |
|                                     |                                             |
|  [ Framework Runner ]     RISCOF (Python harness running DUT vs Spike/Sail)       |
|                                     |                                             |
|  [ Random Testbench ]     Google riscv-dv (SystemVerilog / UVM test generator)    |
|                                     |                                             |
|  [ Formal Proof Engine ]  riscv-formal + SymbiYosys (Bounded model checking)      |
+-----------------------------------------------------------------------------------+

riscv-arch-test and RISCOF

The official compliance suite is riscv-arch-test, maintained by RISC-V International. It is not an exhaustive stress test of microarchitectural timing; rather, it verifies that instruction execution, sign extension, overflow handling, branch offsets, and CSR state transitions conform strictly to the ISA definition.

The framework runner is RISCOF (RISC-V Compatibility Framework):

• A Python-based automation harness that compiles tests using the target toolchain.
• Executes tests in parallel on the design under test (DUT) and a golden reference simulator (Spike or Sail).
• Extracts memory signature dumps at test completion and performs a byte-by-byte differential comparison. A test passes only when the architectural signatures match identically.

Google riscv-dv

Developed by Google, riscv-dv is an open-source SystemVerilog and UVM-based random instruction generator.

Key capabilities:

• Generates valid, executable assembly programs containing complex instruction interleavings, register dependencies, and branch structures.
• Injects stress sequences into speculative execution paths, memory-management units, and privilege-level transitions.
• Cross-compares execution traces between cycle-accurate RTL simulators (VCS, Questa, Verilator) and an ISS (Spike) to discover corner-case bugs in hazard forwarding and out-of-order replay logic.

riscv-formal

Created by Claire Wolf, riscv-formal is a formal verification framework for RISC-V processors.

How it works:

• Instruments the target processor RTL with a standard verification interface (the RVFI monitor), which exposes instruction commit information (instruction word, PC, registers read/written, memory accesses).
• Connects the RVFI signals to formal properties written in SystemVerilog Assertions (SVA).
• Uses SymbiYosys and open-source SMT solvers (Z3, Yices, Boolector) to mathematically prove bounded model checking properties: instruction semantic correctness, register bypass consistency, and CSR behavioral rules.

Open-Source Silicon Toolchains and SoC Frameworks

Moving from RTL design to physical silicon or FPGA bitstreams traditionally required expensive proprietary EDA licenses. Open-source platforms now span the entire physical design flow.

Chipyard and LiteX SoC Generators

Building a complete chip requires bus fabrics, memory controllers, DMA engines, and interrupt routers:

• Chipyard (UC Berkeley): An integrated design environment based on Chisel and TileLink. It automates configuring heterogeneous SoCs combining Rocket or BOOM cores with custom hardware accelerators, HBM controllers, and cache crossbars. It provides seamless integration with FireSim for FPGA-accelerated cycle-accurate network simulation in AWS EC2.
• LiteX (Enjoy-Digital): A Python-based framework using Migen or Amaranth. LiteX automates stitching RISC-V cores (VexRiscv, PicoRV32, Rocket) with DDR3/DDR4 controllers, Ethernet MACs, PCIe endpoints, and video framebuffers across dozens of commercially available FPGA developer kits.

OpenROAD and OpenLane

OpenROAD is an open-source autonomous RTL-to-GDSII flow funded by DARPA. Integrated with OpenLane, it provides an automated script-driven pipeline that takes synthesizable Verilog and produces fabrication-ready GDSII layouts:

• Synthesis via Yosys.
• Static timing analysis via OpenSTA.
• Automated floorplanning, placement, clock tree synthesis (CTS), and routing via OpenROAD.
• Design rule checking (DRC) and layout-versus-schematic (LVS) via Magic and Netgen.

Combined with open process design kits (PDKs) like the SkyWater 130nm and IHP 130nm open PDKs, independent engineers and startups can design, verify, and fabricate physical RISC-V microcontrollers without proprietary software tools.

System Firmware, Operating Systems, and Kernels

The software ecosystem above the hardware is divided into machine-mode firmware, real-time operating systems, and full-featured multi-user kernels.

+-----------------------------------------------------------------------------------+
|                        System Software and Operating Stack                        |
+-----------------------------------------------------------------------------------+
|  [ User Space ]       Debian / Fedora / Ubuntu / Alpine Linux  OR  FreeBSD        |
|                                 |                                                 |
|  [ Supervisor Mode ]  Linux Kernel (Sv39/48/57)  OR  RTOS (FreeRTOS, Zephyr)      |
|                                 |                                                 |
|  [ Firmware Layer ]   OpenSBI (Supervisor Binary Interface, M-Mode Handler)       |
|                                 |                                                 |
|  [ Bootloader ]       U-Boot SPL ---> U-Boot Proper (FDT / Device Tree Parsing)   |
|                                 |                                                 |
|  [ Hardware Layer ]   Physical Core / CSRs / MMIO CLINT / PLIC                    |
+-----------------------------------------------------------------------------------+

OpenSBI (Supervisor Binary Interface)

In the RISC-V privileged specification, the operating system kernel runs in Supervisor mode (S-mode) and cannot directly manipulate Machine-mode (M-mode) CSRs or hardware configuration registers.

OpenSBI is the reference implementation of the RISC-V SBI specification:

• Runs in M-mode and acts as a secure, standardized hardware abstraction layer.
• Provides system services to the OS kernel via ecall instructions: timer management, inter-processor interrupts (IPI), remote TLB flushes, CPU power state control, and early debug console I/O.
• Because Linux targets OpenSBI rather than vendor-specific hardware registers, a single compiled Linux kernel image can boot across completely different SoC architectures.

Real-Time Operating Systems

Embedded systems and microcontroller products rely on real-time kernels with native RISC-V support:

• FreeRTOS: The upstream FreeRTOS kernel provides standard machine-mode and supervisor-mode ports. Context switching is handled through portYIELD (via ecall) and the machine timer interrupt.
• Zephyr Project: Maintained by the Linux Foundation, Zephyr provides first-class support for dozens of RISC-V boards, featuring an integrated device tree model, modular network stacks, and BLE subsystems.
• RT-Thread & Apache NuttX: Full POSIX-compliant RTOS platforms widely used in commercial IoT devices and embedded sensor hubs.

Mainstream Linux and BSD Distributions

Upstream support for RISC-V has progressed rapidly:

• The Linux kernel merged core RISC-V architectural support in version 4.15 (2018), with vector extension 1.0 support merged in version 6.5.
• Debian: Officially adopted riscv64 as a release architecture in 2023, maintaining over 95% package archive parity with x86_64.
• Ubuntu: Publishes official preinstalled server and desktop images for hardware like the StarFive VisionFive 2 and Milk-V Mars.
• Fedora, Arch Linux RISC-V, Alpine, and FreeBSD: Maintain active package repositories and bootable disk images for application-class hardware.

Commercial Silicon and Production Hardware

The RISC-V market is no longer restricted to FPGA prototypes and academic test chips. Production silicon is available at high volumes across multiple commercial market tiers.

+-----------------------------------------------------------------------------------+
|                         Commercial Silicon Product Tiers                          |
+-----------------------------------------------------------------------------------+
|  [ Deeply Embedded / MCU ]  WCH CH32V003 ($0.10) | ESP32-C3 / C6 | GD32VF103      |
|                                                                                   |
|  [ Edge Linux / SBCs ]      Allwinner D1 | StarFive JH7110 | Milk-V Duo (CV1800B) |
|                                                                                   |
|  [ Server / High Compute ]  Sophgo SG2042 (64-core) | Tenstorrent Wormhole / Blackh |
+-----------------------------------------------------------------------------------+

Microcontrollers and Wireless SoCs

These chips serve the internet-of-things (IoT), consumer electronics, and motor control sectors:

• Espressif Systems (ESP32-C3 and ESP32-C6): Espressif transitioned its flagship wireless microcontrollers from Xtensa to RISC-V. The ESP32-C3 features a 160 MHz single-core RV32IMC processor with integrated 2.4 GHz Wi-Fi and Bluetooth 5 (LE). The ESP32-C6 adds Wi-Fi 6, Zigbee, and Thread protocols. Tens of millions of these chips have been manufactured and shipped worldwide.
• WCH (WinChipHead) CH32V Series: Includes the CH32V003, an ultra-low-cost (approximately $0.10 in volume) microcontroller featuring an RV32EC core operating at 48 MHz with 16 KiB Flash and 2 KiB SRAM. It has become a primary alternative to 8-bit microcontrollers (such as STM8 and PIC).
• Bouffalo Lab (BL808 and BL602): The BL808 is a heterogeneous tri-core SoC featuring an RV64IMAFDC application core, an RV32IMFC multimedia core, and an RV32E wireless core, paired with hardware H.264 video encoding and neural network acceleration.
• GigaDevice GD32VF103: Built around the Nuclei Bumblebee RV32IMAC core, designed as a pin-compatible replacement for the ubiquitous STM32F103 microcontroller.

Linux-Capable Application Processors and Single-Board Computers

These SoCs run full desktop operating systems, media stacks, and server workloads:

• StarFive JH7110: Powers the VisionFive 2 single-board computer. Features a quad-core SiFive U74 RV64GC processor running at 1.5 GHz, an Imagination BXE-4-32 GPU, dual Gigabit Ethernet ports, and PCIe 2.0 interfaces. It acts as the workhorse developer board for Linux package maintenance.
• Allwinner D1: Features a single-core Alibaba XuanTie C906 RV64GCV processor running at 1.0 GHz with 0.7.1 vector extension support, powering low-cost single-board computers such as the Nezha and MangoPi MQ-Pro.
• Sophgo CV1800B / SG2002: Powers the Milk-V Duo family. An ultra-affordable ($5 to $9) Linux computer featuring a 1 GHz RV64GC core paired with an integrated 0.5 to 1.0 TOPS neural processing unit.
• Sophgo SG2042: A high-density server processor featuring 64 XuanTie C920 RV64GCV cores clocked at 2.0 GHz, 64 MiB of system L3 cache, quad-channel DDR4 memory controllers, and 32 lanes of PCIe Gen4 connectivity.

Commercial Silicon Summary

Practical Workflow: From C Source to Emulation and Silicon

To understand how the tools interact during development, consider the standard lifecycle of compiling, verifying, and deploying a hardware-software application:

[ Step 1: Write C Code ] ---> [ Step 2: Compile & Link ] ---> [ Step 3: Functional Emulation ]
                                                                        |
                                                                        v
[ Step 5: Physical Deployment ] <--- [ Step 4: Cycle-Accurate RTL ] <---+

Step 1: Compiling with Explicit Extensions

Software targeting a specific core configuration must match its exact microarchitectural features:

riscv32-unknown-elf-gcc -O2 -march=rv32im_zicsr -mabi=ilp32 \
    -nostdlib -T link.ld crt0.S main.c -o firmware.elf

Step 2: Validating on an Instruction Simulator

Before compiling RTL, verify functional correctness in Spike or QEMU:

# Generate disassembly trace
riscv32-unknown-elf-objdump -d firmware.elf > firmware.asm

# Execute under Spike with register commit logging
spike --isa=rv32im_zicsr -l firmware.elf 2> commit.log

Step 3: Simulating Cycle-Accurate RTL in Verilator

Convert the ELF binary to memory initialization files and run cycle-accurate Verilog verification:

# Convert ELF sections to Verilog hex format
riscv32-unknown-elf-objcopy -O verilog firmware.elf memory.hex

# Run compiled Verilator testbench
./Vcore_top +mem_init=memory.hex +vcd_dump=trace.vcd

Step 4: Physical Silicon or FPGA Flashing

Transfer the binary to physical hardware using OpenOCD and a standard JTAG debugger (such as a FT2232H or CMSIS-DAP adapter):

openocd -f interface/ftdi/esp32_devkitj_v1.cfg \
        -f target/esp32c3.cfg \
        -c "program firmware.elf verify reset exit"

Ecosystem Maturity and Remaining Industry Challenges

The RISC-V ecosystem has matured substantially over the past five years, transitioning from an academic experiment into a viable commercial alternative to ARM and x86. However, several technical challenges remain:

• Vector Extension Fragmentation: Early application silicon (including the Allwinner D1 and XuanTie C906/C910) fabricated implementations of the draft Vector 0.7.1 specification before the official Vector 1.0 specification was ratified. Because the instruction encodings and register layouts differ, software compiled for standard rv64gcv cannot run on older vector chips without recompilation or emulation layers.
• Server Platform Standardization: While ARM created the Server Base System Architecture (SBSA) and Server Base Boot Requirements (SBBR) to guarantee enterprise OS compatibility across different hardware vendors, RISC-V is still standardizing its equivalents: the RISC-V Server SoC Specification and Basic Boot and Runtime Services (BRS).
• Profile Adoption: To prevent fragmentation caused by arbitrary combinations of optional extensions, RISC-V International established application profiles (such as RVA20, RVA22, and RVA23). Moving the ecosystem toward uniform compliance with these profiles ensures that Linux distribution binary packages will execute predictably across silicon from all vendors.

The ecosystem provides complete coverage from compiler backends and formal verification engines up to multi-core production processors. For embedded microcontrollers, edge AI hardware, and custom application-specific silicon, the tools and production silicon are ready for deployment today.

References and Sources

• RISC-V International Technical Specifications, Unprivileged and Privileged Architecture Manuals (riscv.org).
• GCC and LLVM RISC-V Backend Documentation, GNU Compiler Collection and LLVM Project.
• Spike ISA Simulator and RISC-V Proxy Kernel (github.com/riscv-software-src/riscv-isa-sim).
• Sail RISC-V Formal Specification (github.com/riscv/sail-riscv).
• OpenSBI Supervisor Binary Interface Implementation (github.com/riscv-software-src/opensbi).
• Google riscv-dv Instruction Generator (github.com/google/riscv-dv).
• lowRISC Ibex Processor Core Technical Reference Manual (ibex-core.readthedocs.io).
• OpenHW Group CV32E40P Core Verification and RTL Repository (github.com/openhwgroup/cv32e40p).
• XiangShan High-Performance Processor Project Documentation (github.com/OpenXiangShan/XiangShan).
• StarFive JH7110 Technical Reference Manual and VisionFive 2 Documentation (starfivetech.com).
• Espressif Systems ESP32-C3 and ESP32-C6 Technical Reference Manuals (espressif.com).