At Hot Chips 2026 we are getting an update on RISC-V Standards and Adoption. This article is being written live, but since we are falling behind, it will be published a bit later as part of our RISC-V coverage.
SiFive Update on RISC-V Standards and Adoption at Hot Chips 2026
RISC-V marks its official birthday as May 18, 2010, giving the project 16 years of history by this Hot Chips. This timeline shown here runs from the first UC Berkeley work, through the founding of the RISC-V Foundation and early commercial offerings, to the current push into server processors with the first RVA23 silicon. It feels like we have done more articles on RISC-V than we have seen platforms with RISC-V as the main CPU at this point.
SiFive’s opening point is that RISC-V is a global, community-developed standard not tied to any single company’s fortunes. That openness has produced a far larger set of processor implementations than any prior ISA, ranging from licensable IP cores to open-source cores that fit in just 125 FPGA LUTs.
To keep the many RISC-V variants manageable, the spec is split into modular layers. Base ISAs define the fundamentals, extensions bolt on features, profiles set the mandatory combination for a vertical, and platform standards go beyond the ISA to whole hardware subsystems.
Four base ISAs are ratified today, RV32I, RV64I, RV32E, and RV64E, which differ in address width and register count. Further bases are in development, including a CHERI variant that adds hardware capabilities and future RV128 designs for a 128-bit address space.
Early RISC-V extensions used single letters like M for multiply and divide or V for vector, with G as an alias for the common MAFD set. Later work moved to the Z* naming scheme for unprivileged extensions, grouping them by category so the first letter after Z tells you what the extension touches.
Encoding space in RISC-V is classified so vendors and the standards body know who owns what. These categories shown here: standard, reserved, custom, non-standard, and non-conforming, keep vendor-specific features like the Xsfvqdotq string from colliding with future standard extensions.
SiFive stresses that RISC-V specs describe executing harts inside an execution environment, not just raw hardware. A hart is the hardware thread, while the execution environment defines things like initial state, memory properties, and interrupt handling, which means the Linux user ABI counts as one such specification.
RISC-V privilege levels are laid out as user, supervisor, and machine modes. A hypervisor extension upgrades the picture with virtual user and supervisor modes plus two-stage address translation, and a debug mode serves hardware debugging.
Privilege layering is kept clean because no spec assumes a higher-privilege mode exists elsewhere. Extensions are separated by which mode they are visible in, which is why names break into Sm for machine, Sh for hypervisor, Ss for supervisor, Sv for virtual memory, and Sd for debug.
An ISA string is built from a base name followed by its extensions, and the naming is case-insensitive. Fully expanded, a modern application string stretches out across dozens of Z, S, and V extensions, which is why profiles matter for keeping software portable.
This vector extension, ratified in 2021, adds 32 vector registers, the number of which is implementation-dependent. Since the ISA supports vector-length agnostic code, one binary can run correctly across datapaths from 32-bit embedded parts up to 2048-bit AI accelerators without recompilation.
Matrix support is being worked out through a set of complementary approaches. RISC-V groups them as AME, IME, and VME for where matrix elements live and how they execute, plus a fast-track vector-based option, so silicon vendors can pick the implementation that fits their datapath.
SiFive’s talk places AI compute on a spectrum of machine organization. A scalar, vector, and matrix RISC-V core can sit in a CPU-style host, a device, or a fully self-hosted system, a pattern the presentation traces back to a 1968 paper on display processors.
SiFive argues RISC-V is the only ISA that works well across every AI role at once. It can serve as the host ISA, as with NVIDIA’s CUDA stack port, as the device ISA in many accelerators, and as a self-hosted ISA for edge AI and agentic CPUs.
Security starts at the lowest levels of the ISA. Physical memory protection registers let machine mode control access from lower-privilege code, and RISC-V Worlds provides bus-level isolation by tagging transactions with a world ID so target-side checks can enforce permissions.
Confidential compute gets its own mechanism in the form of supervisor domains. A memory-resident page-based protection table lets the machine mode isolate multiple supervisor or hypervisor stacks, and the IOMMU mirrors the same page-table format.
Beyond the basics, the ISA carries a long list of additional security features. Scalar and vector crypto, data-independent execution time, control-flow integrity, and pointer masking are joined by work-in-progress items like CHERI, speculation barriers, memory tagging, and memory encryption contexts.
Binary software ecosystems face a real tension between targeting the lowest common denominator and adopting new features. RISC-V’s answer is the RVA profile, a roadmap of mandatory ISA features that hardware implementers commit to providing each generation so software can rely on them.
RVA profiles target rich application-processor ecosystems such as Android and Linux distros. These ratified generations run from RVA20, which captures the earlier RV64GC baseline, through RVA22, to RVA23, ratified in October 2024 with mandatory vectors and a mandatory hypervisor.
Beyond the mandatory extensions, each profile defines four kinds of options. Localized options cover jurisdictional requirements, development options are likely future mandates, expansion options carry big implementation overhead, and transitory options may or may not survive in the profile.
Option lists are deliberately kept smaller than the full set of ISA extensions. Localized and expansion options are coarse-grained to minimize the software support cost, while development options can be finer-grained because they are expected to become mandatory.
RVA releases come in two flavors. Major releases add substantial new mandatory functionality, as RVA20 and RVA23 did, while future minor releases only add options so that new standard software keeps running on hardware from a previous major release.
RVB23 is a separate, also-ratified profile that serves a different purpose from RVA. It targets application processors built with custom software through builds like Yocto and OpenEmbedded rather than binary distributions, and future RVB profiles will evolve on their own cadence.
ISA strings today describe what a feature does, not how fast it runs. That gap matters for things like misaligned accesses, where software pessimistically codes around them even when high-performance cores handle them quickly, so the spec adds optimization guidance options to align hardware and software.
Two optimization guidance options launch the effort. Under Oilsm, software assumes misaligned loads and stores are handled efficiently, while Ovlt assumes microarchitectures optimize based on the dynamic value in the vector-length register rather than static loop shapes.
For the server market, a platform spec ties hardware together. It calls for RVA23-compliant processors, standard RISC-V AIA interrupts, PCIe and IOMMU, UEFI and ACPI, TPM, and BMC management over MCTP, PLDM, Redfish, and IPMI so that RISC-V vendors stay compatible with each other and with industry server standards.
This same profile logic extends down to microcontrollers. A richer RVM standard mandates many extensions for the ISA and defines a subsystem with standard fast interrupts, nested sPMP protection, RISC-V Worlds security, and debug and trace support.
Ok this is changing into less of a here is an update about RISC-V and is now transitioning into a “mythbusting” style of presentation.
A common criticism is that RISC-V is fragmented. Here they are arguing that RISC-V is diverse.
Countering the charge of fragmentation with concrete comparisons. x86 spans two vendors with different hypervisor and IOMMU specs, while Arm has shipped four distinct vector architectures, yet RISC-V reuses a single vector extension across application cores, AI accelerators, and embedded parts.
This complaint that RISC-V has too many extensions is put in context with raw counts. RISC-V has roughly 200 extensions, compared with about 400 for AArch64 and 800 for x86_64, and RISC-V International argues it manages those extensions to keep them reusable.
SiFive pushes back on the idea that RISC-V is only attractive because it is cheap. Competition can indeed lower cost, but it also drives performance, power, and features, and RISC-V pairs the freedom to innovate with a standard software stack that legacy ISAs cannot offer together.
Variable-length instruction encoding is often raised as a RISC-V weakness. Here they argue it is a minor front-end consideration, since the instruction length is encoded in two bits, and that it improves code density, pointing out that ARM and POWER have moved toward prefix instructions as fixed-size encodings ran out of room.
Another myth claims that RISC-V needs instruction fusion to remain competitive. A single base RISC-V instruction already handles compare and branch, while x86 and Arm need fusion for that path, and that optional fusion lets simple instructions stay flexible without mandating complex macroinstructions.
This closing myth is that RISC-V cannot deliver high performance.
I am not exactly a fan of the whole mythbusting thing. RISC-V is used for many controllers. We need useful products now.
Final Words
RISC-V has moved from an academic project into a standardized, profiled ecosystem aimed squarely at servers and AI. First RVA23 servers arriving this year are the practical signal that the standards work documented in this talk is landing in real hardware. Their progress is worth watching as RISC-V moves further into the data center.
