Overview

The supplied evidence treats the RISC-V ISA as the architectural contract used to validate processor implementations and as a base for proposed extensions. The RISC-V ISA is described as an open instruction-set architecture that has enabled rapid processor innovation, with verification flows that compare an RTL processor core against an instruction-set simulator (ISS) reference model and check that both executions produce matching architectural state.

Modular ISA Profiles and Extensions

The evidence refers to RISC-V using its modular profile notation. Concrete profiles cited include RV64GC, RV64GCHX, and RV64GCX for 64-bit cores and RV32IMF for the Hornet core (32-bit RISC-V with Integer, Multiply, and Float extensions). Rocket is described as supporting new extensions such as the hypervisor and cryptography extensions, which together yield the RV64GCHX profile in the MorFuzz evaluation.

Control and Status Registers (CSRs)

CSRs are highlighted as an important part of RISC-V verification because their behavior can include legal implementation choices. WARL fields can be written with any value, but reads return only legal values, allowing software to query CSRs for information about core capabilities. Compared with instruction-set specifications, CSR behavior is less rigidly defined and can make testing more challenging.

The evidence gives examples of monitored privileged CSRs and their roles:

• mscratch: holds a pointer to machine-mode context space while a hart executes in a lower privilege level
• {m,s}epc: contains the PC of an instruction that caused an exception for machine or supervisor mode
• sscratch: holds a pointer to supervisor-mode context space while a hart executes in user mode

Co-simulation-based verification

A cited RISC-V processor-verification testbench is implemented in SystemC and co-simulates an RTL core with an ISS reference model. Its controller repeatedly advances the RTL core and the ISS by one instruction and compares their execution states. If the states do not match, the testbench reports an error that must be analyzed and fixed; otherwise, testing continues until the available testing time is exhausted.

RISCV-DV-based random instruction verification

A separate verification framework combines RISCV-DV for random instruction generation with both open-source and commercial tools. The open flow uses a Python-based flow with the Spike ISS, while the commercial flow uses Xcelium. A custom tracer integrated into the Hornet RV32IMF core captures execution logs that are automatically compared with Spike through structured CSV-based scripts. The framework is described as systematically detecting subtle errors often missed by directed tests, including incorrect handling of IEEE-754 rounding modes and precision loss in arithmetic units such as division and square root. It uncovered and resolved multiple floating-point bugs in Hornet, demonstrating that ensuring compliance with RISC-V and IEEE-754 standards provides a scalable foundation for verifying cores with advanced arithmetic capabilities.

ProcessorFuzz and CSR-transition feedback

ProcessorFuzz is a fuzzing approach for real-world open-source RISC-V processor designs. It builds extended trace logs using an ISA simulator and uses CSR-transition coverage to decide whether an input is interesting. When the transition unit determines that an input produces a unique CSR transition, ProcessorFuzz launches RTL simulation, generates an extended RTL trace log, and compares it with the extended ISA trace log. A difference between the logs is treated as a potential processor-design bug that requires investigation by a verification engineer.

ProcessorFuzz extends the Spike open-source ISA simulator to store monitored CSR values. The same evaluation uses Verilator as the open-source RTL simulator and compares CSR-transition coverage with register-coverage feedback while keeping the mutation engine fixed.

MorFuzz and runtime instruction morphing

MorFuzz is a processor-fuzzing framework that performs runtime instruction morphing on the RISC-V 64-bit architecture. The morpher acts on fetched instructions and only replaces the wires between the fetch unit and the decode unit, ensuring that morphed instructions keep the instruction fetch offset consistent with the pipeline front-end and do not require modification of the pipeline back-end. To ensure that the reference model can perform the same morphing as the DUT, the morpher maintains a morphing map keyed by the instruction before morphing and its address, with the morphed instruction as the value. This design ensures that both models always execute deterministic and identical morphed instructions.

State synchronization in MorFuzz must satisfy three prerequisites to be considered a legal difference:

1. Only instructions involving operations beyond the verification scope can perform subsequent steps. This limits the types of instructions that are allowed to trigger state synchronization to CSR instructions and memory operation instructions.
2. The control flow information of the DUT must pass the commitment stage check. If the DUT incorrectly approves access to privileged registers or reserved address space, an exception will be thrown on the simulator side due to insufficient permissions, and MorFuzz will prevent synchronization after observing a program counter violation during the commitment stage.
3. Mismatched write-back values are limited to the CSR WARL fields defined in the specification or the data reading from peripheral addresses outside the specification.

For hardware simulation, MorFuzz uses the Synopsys VCS RTL simulator. All hardware modules are translated to Verilog code and then compiled into a host executable binary. MorFuzz also supports a hardware coverage matrix that is compatible with the control-register coverage proposed by DifuzzRTL: a FIRRTL pass instruments all control registers, and the instrumented circuits count the different states triggered in each module.

MorFuzz reports that it found 17 new bugs and two already known bugs across real-world processors, with 13 assigned CVE numbers. The evaluation used three popular RISC-V cores that are all capable of booting and running Linux. Specific bug examples from the CVA6 core include:

• Bug B8: the CVA6 decoder accepts sfence.vma as valid even when its rd field is non-zero, while the specification says sfence.vma has a zero rd field.
• Bug B9: the CVA6 decoder handles dret with a non-zero rd field as if it were a legal dret, even though the specification requires rd to be zero.
• Bug B10: when executing a non-standard fence.i/fence with a non-zero rd field, CVA6 throws an exception, although for forward compatibility implementations must ignore the rd fields in fence.i/fence and standard software must clear them.

ISA Extensions Discussed in the Evidence

Load-Acquire and Store-Release Extension

The public context includes a project that explores adding load-acquire and store-release instructions to the RISC-V ISA. The motivation is to allow hardware to use a weaker memory model that simplifies the design and increases performance, with explicit acquire and release semantics providing a primitive for expressing only the ordering required for correctness. Support was added to the herd formal memory model, the gem5 cycle-approximate simulator, and the LLVM/Clang toolchain. Because these instructions do not exist in the RISC-V standard, the authors emphasize the urgency of ratifying explicit load-acquire/store-release instructions to prevent multiple ABI implementations and ecosystem fragmentation. For workloads with a high degree of sharing and heavy contention, the impact of less memory ordering is muted, but the proposed changes successfully encode the desired semantics.

GPGPU and 3D-Graphics Extension (Vortex)

A second extension proposal in the public context adds GPGPU and graphics support to the RISC-V ISA. The proposal aims to minimize ISA changes so that corresponding changes to the open-source ecosystem are also minimal and sustainable. To demonstrate the feasibility of the minimally extended RISC-V ISA, the Vortex project implemented the complete software and hardware stacks of a PCIe-based soft GPU on FPGA, supporting OpenCL and OpenGL. Vortex is described as scaling up to 32 cores on an Altera Stratix 10 FPGA, delivering a peak performance of 25.6 GFlops at 200 MHz.

RISC-V Processor Cores in the Evidence

Several real-world RISC-V cores are described:

• Rocket: a five-stage, single-issue, in-order scalar processor written in Chisel, with a delayed write-back pipeline that allows the processor to commit long-latency instructions without carrying write-back data. The evidence describes Rocket as the world's first RISC-V processor open-sourced by UC Berkeley, still actively supporting new extensions (e.g., hypervisor and cryptography), having been taped out dozens of times and extensively verified by academia and industry. Its ISA profile in the MorFuzz evaluation is RV64GCHX, and it is also described in the previous evidence as a Chisel HDL-based, open-source, general-purpose, in-order RISC-V processor core generated by the Rocket Chip SoC Generator framework.

• CVA6: an open-source 64-bit in-order RISC-V processor core written in SystemVerilog. Its six-stage pipeline is single-issue but has independent internal execution functional units, allowing it to commit multiple instructions simultaneously. CVA6 has been taped out in 22nm technology and runs at up to 1.7 GHz. Its ISA profile in the MorFuzz evaluation is RV64GC.

• BOOM (Berkeley Out-of-Order Machine): the third generation, an out-of-order superscalar processor written in Chisel. The MorFuzz evaluation uses the triple-issue LargeBoom configuration. The latest BOOM has been verified on FPGA and achieves better performance than its predecessor. Its ISA profile in the MorFuzz evaluation is RV64GCX. The same processor family is referenced in the previous evidence as the target of bugs previously reported by DIFUZZRTL.

• Hornet RV32IMF: a 32-bit RISC-V core with Integer, Multiply, and Float extensions, used as the DUT in the RISCV-DV verification framework. The framework uncovered and resolved multiple floating-point bugs in Hornet.