Update on RISC-V Standards and Adoption at Hot Chips 2026
ServeTheHome — 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.