Announcer
The following program features simulated voices generated for educational and technical exploration.
Sam Dietrich
Good evening. I'm Sam Dietrich.
Kara Rousseau
And I'm Kara Rousseau. Welcome to Simulectics Radio.
Kara Rousseau
Tonight we're examining open instruction set architectures, specifically RISC-V, which has emerged as a viable alternative to proprietary architectures like x86 and ARM. An instruction set architecture defines the boundary between hardware and software—the machine-level operations a processor can execute. For decades, this boundary was controlled by companies that licensed their ISAs, creating dependencies and business constraints. RISC-V represents a different model—an open standard developed by the academic community, freely available for anyone to implement without licensing fees. This openness enables architectural experimentation and reduces barriers to custom processor design. But establishing an ecosystem around a new ISA requires more than technical merit. You need compilers, operating systems, development tools, and enough adoption to justify software support. The question isn't whether RISC-V is technically sound—it clearly is—but whether it can overcome network effects favoring established architectures.
Sam Dietrich
From a hardware perspective, instruction set architecture is the most fundamental constraint on processor design. Every microarchitectural decision—pipeline depth, branch prediction, cache hierarchy—must respect the ISA's semantic requirements. x86 accumulated decades of extensions for backward compatibility, creating enormous complexity. Modern x86 processors spend significant resources decoding variable-length instructions into internal microops. ARM offered a cleaner slate with fixed-length instructions and simpler encoding, but remained proprietary. RISC-V follows the RISC philosophy—simple, regular instruction formats, load-store architecture, orthogonal register usage. The base integer instruction set is remarkably compact, just forty-seven instructions. Extensions add floating-point, atomics, vector operations, but the core remains simple. This simplicity enables smaller, more power-efficient implementations. The challenge is balancing extensibility—allowing custom instructions for domain-specific acceleration—against standardization needed for software compatibility.
Kara Rousseau
Joining us to discuss RISC-V and open instruction set architectures is Dr. Krste Asanović, Professor of Computer Science at University of California Berkeley and one of the original creators of RISC-V. Dr. Asanović has spent decades researching computer architecture and led the development of RISC-V beginning in 2010 as a research and teaching platform. He co-founded SiFive, the first company building commercial RISC-V processors, and continues advancing the RISC-V ecosystem through the RISC-V International organization. Dr. Asanović, welcome.
Dr. Krste Asanović
Thank you. It's been fascinating watching RISC-V evolve from academic project to industrial reality.
Sam Dietrich
Let's start with the motivation. What problems were you trying to solve when you started RISC-V?
Dr. Krste Asanović
The original motivation was purely pragmatic—we needed a clean ISA for research and teaching that we could freely modify without licensing restrictions. Berkeley had used MIPS, SPARC, and ARM over the years, but each had limitations. MIPS licensing became expensive. SPARC was controlled by Sun, then Oracle. ARM wouldn't allow architectural modifications. We needed something we could extend for research into parallel architectures, security features, domain-specific acceleration. At the same time, we were frustrated that every new processor startup faced enormous ISA licensing costs and restrictions. The semiconductor industry had standardized everything else—manufacturing processes, EDA tools, verification methodologies—but ISAs remained proprietary. This seemed arbitrary and inefficient. An open ISA would enable the same kind of innovation we see in open-source software.
Kara Rousseau
How did you balance simplicity with completeness? Every ISA faces pressure to add features, but bloat undermines the original design.
Dr. Krste Asanović
We learned from decades of ISA evolution what not to do. x86 shows the consequences of endless backward compatibility—the instruction set became so complex that Intel and AMD basically implement RISC cores underneath that translate x86 instructions. ARM avoided some of that by having clean breaks—ARM to Thumb to ARMv8—but still accumulated considerable complexity. RISC-V uses a modular approach. The base integer ISA, which we call RV32I or RV64I, is frozen and will never change. It's minimal but sufficient for general computation. Then we have standardized extensions—M for multiplication, A for atomics, F and D for floating-point, C for compressed instructions. You only implement the extensions you need. This modularity enables tiny embedded processors with just the base ISA, or large application processors with all extensions.
Sam Dietrich
What about custom extensions? If everyone adds proprietary instructions, doesn't that fragment the ecosystem?
Dr. Krste Asanović
That's the key tension. Custom instructions enable domain-specific optimization—if you're doing cryptography or machine learning, custom instructions can provide order-of-magnitude performance improvements. But if software can't rely on those instructions being present, portability suffers. RISC-V addresses this through opcode space allocation. The base ISA reserves space for standard extensions, vendor-specific extensions, and custom instructions. Software can probe for extension support at runtime and use optimized paths when available, falling back to base ISA otherwise. The standard extensions go through a rigorous ratification process to ensure they're generally useful and well-designed. This is similar to how x86 has SSE, AVX, and other optional extensions. The difference is that with RISC-V, vendors can innovate in the custom space without waiting for committee approval, then if an extension proves useful, it can be standardized.
Kara Rousseau
How do compilers handle this extensibility? Traditional compilers assume a fixed ISA or a small set of well-known extensions.
Dr. Krste Asanović
Compiler support is critical to making custom extensions practical. For standard RISC-V extensions, the major compilers—GCC, LLVM, and others—have full support. For custom extensions, we've developed several approaches. At the simplest level, inline assembly lets programmers use custom instructions directly. For better integration, compiler intrinsics provide C functions that map to specific instructions. For broader optimization opportunities, you can extend the compiler backend to recognize patterns that can be accelerated with custom instructions. The most sophisticated approach uses compiler frameworks like LLVM where you can add custom instruction selection, register allocation, and scheduling for your extensions. This is significant work, but for performance-critical applications, it's justified. The key insight is that custom instructions don't need universal compiler support—they need support in the specific toolchains used for applications that benefit from them.
Sam Dietrich
What about verification? One advantage of licensing ARM or x86 is getting a known-good design. With RISC-V, everyone implements their own processor. How do you ensure correctness?
Dr. Krste Asanović
Verification is challenging regardless of whether you're implementing a proprietary or open ISA. ARM licensees still have to verify their implementations—ARM provides the specification, not the implementation. RISC-V provides formal specifications using methods like Sail, a language for precisely describing ISA semantics. These can be used to generate reference implementations and compliance tests. The RISC-V International organization maintains architectural tests—thousands of test programs that verify correct instruction behavior. There are also formal models that can be used with model checking and theorem proving. Additionally, several high-quality open-source RISC-V cores exist—like Rocket, BOOM, and others from Berkeley, as well as commercial implementations from SiFive and other companies. These provide reference points for verification. The openness actually helps verification because the community can contribute tests and find bugs across different implementations rather than having bugs hide in proprietary cores.
Kara Rousseau
Let's talk about the ecosystem challenge. Software support determines whether an ISA succeeds. How has RISC-V approached building that ecosystem?
Dr. Krste Asanović
Ecosystem development has been slower than pure technical progress but has accelerated significantly. Linux has had RISC-V support since 2017, with all major distributions now available. The GNU toolchain—GCC, binutils, gdb—has full RISC-V support. LLVM added RISC-V as a tier-one target. For higher-level languages, Java, Go, Rust, and others support RISC-V. The challenge isn't basic infrastructure—it's the long tail of applications and libraries. Getting a Linux distribution running is one thing. Having every piece of software someone might want to run optimized and tested for RISC-V is another. We're seeing increasing adoption in embedded systems where ecosystem requirements are smaller and custom hardware is common. High-performance computing is another area—vector extensions make RISC-V attractive for scientific computation. Mobile and desktop are harder because of established ecosystems around ARM and x86, but we're making progress.
Sam Dietrich
What about performance? Can RISC-V implementations compete with highly optimized x86 and ARM processors?
Dr. Krste Asanović
Performance depends entirely on implementation, not ISA. The ISA defines what instructions do, not how fast they execute. A simple in-order RISC-V core will be slower than a complex out-of-order x86 core with large caches and sophisticated branch prediction. But there's nothing preventing RISC-V implementations from using the same microarchitectural techniques—out-of-order execution, speculative execution, large instruction windows. SiFive and other companies are building high-performance RISC-V cores competitive with ARM Cortex-A series. The advantage RISC-V offers is simpler instruction decode, which slightly reduces power and area. The bigger advantage is flexibility—you can optimize the implementation for specific workloads without ISA constraints. For general-purpose computing, performance will converge because everyone uses similar microarchitectural techniques. For specialized applications, RISC-V's extensibility enables significant optimizations impossible with fixed ISAs.
Kara Rousseau
Vector processing seems particularly important for RISC-V. How does the vector extension differ from SIMD approaches like SSE or NEON?
Dr. Krste Asanović
The RISC-V vector extension uses a more flexible approach than fixed-width SIMD. Traditional SIMD has fixed vector widths—128-bit, 256-bit, 512-bit. Software must be written for specific widths and recompiled for different implementations. RISC-V vectors use a vector-length agnostic model. Software specifies operations on vectors without knowing the hardware vector length. The processor executes these operations using whatever vector width it implements—maybe 128-bit, maybe 2048-bit. This enables binary portability across different vector lengths while allowing each implementation to optimize for its application domain. A tiny embedded processor might use short vectors. A supercomputer might use very long vectors. The same code runs on both, automatically exploiting available parallelism. This is similar to the old Cray vector machines, adapted for modern heterogeneous computing. It requires more sophisticated compiler and hardware support but provides better scalability than fixed SIMD.
Sam Dietrich
Memory consistency models are another critical ISA aspect. How does RISC-V handle this given the complexity we've discussed in previous episodes?
Dr. Krste Asanović
RISC-V learned from decades of memory model confusion in other ISAs. The base specification defines a weak memory model similar to ARM—loads and stores can be reordered unless separated by explicit fence instructions. This gives hardware maximum optimization flexibility. But we also defined a total store ordering extension, TSO, which provides x86-like sequential consistency for loads and stores. Implementations can support either or both. Software specifies which model it requires. Most modern software is written to handle weak ordering using atomics and fences appropriately, so the weak model is usually sufficient. TSO exists primarily for porting software from x86 that assumes stronger ordering. The key lesson from x86 and ARM's memory model evolution is to specify the model precisely from the beginning, which we did using formal methods. This prevents the ambiguity that plagued earlier ISAs.
Kara Rousseau
What about security? Recent vulnerabilities like Spectre and Meltdown exploited microarchitectural behaviors. Does RISC-V address these?
Dr. Krste Asanović
Spectre and Meltdown are microarchitectural vulnerabilities, not ISA issues—they can affect any speculative out-of-order processor regardless of ISA. RISC-V itself doesn't prevent these attacks, but it provides mechanisms for mitigation. The ISA includes instructions for flushing caches, invalidating TLBs, and controlling speculation. Specific implementations must decide how aggressively to speculate and what mitigations to include. The advantage of an open ISA is transparency—researchers can analyze and propose improvements without NDA restrictions. We've seen proposals for architectural features like context-based isolation, hardware support for control-flow integrity, and memory tagging for capability-based security. The openness enables rapid iteration on security features as new threats emerge, rather than waiting for proprietary vendors to respond.
Sam Dietrich
Looking at adoption, where has RISC-V succeeded, and where does it face the most resistance?
Dr. Krste Asanović
RISC-V has seen strongest adoption in markets where proprietary ISA costs or restrictions are most burdensome. In embedded systems, companies are shipping billions of RISC-V cores for microcontrollers, IoT devices, and sensor applications. Western Digital announced they're using RISC-V cores in storage controllers. SiFive is selling application processors for embedded Linux. In China, several companies are developing RISC-V processors partly for supply chain independence from foreign ISA licensing. Academia has widely adopted RISC-V for research. Resistance comes primarily from established ecosystems. Data center computing is dominated by x86 with enormous software investment. Mobile is ARM territory with mature toolchains and optimized libraries. Breaking into these markets requires not just competitive hardware but demonstrating sufficient advantage to justify transition costs. We're seeing interest in specialized accelerators where RISC-V extensibility provides clear value—AI accelerators, network processors, image processing. These can establish footholds that gradually expand.
Kara Rousseau
How does governance work? Who controls RISC-V's evolution, and how do you prevent fragmentation or capture by specific commercial interests?
Dr. Krste Asanović
RISC-V International is a non-profit organization that manages the specification. Members include companies, universities, and individuals. Technical work happens in committees focused on different aspects—base ISA, privileged architecture, vectors, security, and so forth. Decisions require member voting, with processes designed to prevent any single entity from controlling the standard. The specification itself is freely available—no licensing fees, no membership required to implement RISC-V. Membership is necessary to participate in specification development and vote on changes. This is similar to other successful open standards like Ethernet or USB. The risk of fragmentation is managed through ratification processes—extensions must go through review and approval before becoming official. Custom extensions are fine for proprietary use, but standardization ensures interoperability where it matters. It's a balance between innovation freedom and ecosystem coherence.
Sam Dietrich
What technical challenges remain? Where does RISC-V still need development?
Dr. Krste Asanović
Several areas need continued work. The hypervisor specification is stabilizing but still evolving. Security extensions for things like pointer authentication and memory tagging are in development. The vector extension is ratified but implementations are just emerging, so we're learning what works in practice. There's ongoing work on packed-SIMD extensions for machine learning and digital signal processing. Bit manipulation extensions were recently ratified. The debug specification needs refinement based on implementation experience. Beyond ISA features, ecosystem development continues—better debugging tools, profilers, simulators. One interesting challenge is defining platform specifications. RISC-V is deliberately minimal about non-CPU aspects like interrupt controllers or timer interfaces to allow flexibility. But software needs some standardization for portability. We're developing platform specifications for embedded, server, and other domains that specify these details.
Kara Rousseau
How do you see RISC-V evolving over the next decade? What's the vision for where this goes?
Dr. Krste Asanović
The goal is ubiquity—RISC-V becomes the default choice for new processor designs, the way Linux became default for new operating systems or Ethernet for networking. We're seeing this trajectory in embedded systems already. The next frontier is higher-performance computing—workstations, servers, HPC. This requires not just technical capability but ecosystem maturity. I expect we'll see RISC-V in more specialized accelerators, eventually leading to heterogeneous systems with RISC-V control cores and various accelerators. The open nature enables innovation impossible with proprietary ISAs—academic research can directly influence commercial products, and companies can collaborate on shared infrastructure while competing on implementation. Long term, I hope RISC-V demonstrates that fundamental infrastructure benefits from openness and standardization, even in competitive markets. The ISA shouldn't be a competitive differentiator—the implementation should be.
Sam Dietrich
Dr. Asanović, thank you for this examination of RISC-V and the broader implications of open instruction set architectures.
Dr. Krste Asanović
Thank you. It's exciting to see RISC-V mature from research project to viable alternative architecture.
Kara Rousseau
That's our program for tonight. Until tomorrow, may your instruction sets remain orthogonal and your pipeline hazards minimal.
Sam Dietrich
And your custom extensions always backward compatible. Good night.