Overview

An Instruction Set Architecture (ISA) describes the instruction-level capabilities exposed by a processor or accelerator implementation. Across the provided evidence, the ISA plays multiple principal roles:

1. It names and structures processor capabilities, as in RISC-V base ISAs plus extensions.
2. It defines the operation kinds and functional classes that drive a verification model, as in the MIPS-I case study used to motivate Constrained-Random Verification (CRV).
3. It serves as the abstraction for specialized accelerators, such as the proposed ISA for processing-in-memory (PIM) deep neural network (DNN) accelerators.
4. It is the target of testability research, including AI-driven test generation, statistical fault injection, system-level testing, design-for-test (DfT) architectures, and hardware-software co-verification.
5. It functions as a unit of portability, with software package build repair being a critical task during migration across ISAs.

RISC-V ISA structure

In the cited RISC-V example, a core implementation is described by combining an integer base ISA with extensions. The evidence states that instruction set extensions are appended to the name of the integer base ISA to name the capabilities of a core implementation. For example, a 32-bit RISC-V processor with a multiplication unit, CSR instructions, Fence support, and compressed-instruction support is named RV32IMCZicsrZifencei.

The same evidence identifies three RISC-V integer base ISAs:

These base ISAs define core instruction categories such as integer calculations, program control, load/store operations, and debugging instructions.

The RISC-V ISA is extensible, and the testability survey notes that RISC-V designs are "highly configurable" and that "comprehensive test architectures combine structural techniques with functional, compliance, and coverage-driven methods tailored for RISC-V's extensible ISA."

MIPS-I functional classes and operation modeling

A separate verification case study uses the MIPS-I instruction set as the design under test. The MIPS-I instruction set is organized into four functional classes: no operation, load and store, computational, and control.

Within an object-oriented SystemVerilog stimulus model, three levels of transaction abstraction — operations, instructions, and instruction scenarios — are modeled as classes implemented in a bottom-up manner. Each transaction is a class with three components:

• Properties — fields describing the transaction and other supporting information. For example, an ADD operation has two source registers and a destination register. A task can display the same transaction in assembly syntax (ADD R10, R3, R5), and a function can pack it into its binary representation (000000_00011_00101_01010_00000_100000).
• Constraints — code describing the relationships between properties, including the encoding rules for operations that use a function field.
• Methods — functions and tasks that perform transaction-level actions, such as rendering assembly syntax or packing binary.

The operation class encapsulates the operation kind, the list of operands, and other properties. A kind property distinguishes which operation the object represents; it is an enumerated type holding a full listing of the supported opcodes as defined by the instruction set architecture. A separate random property is used to describe the functional class of the operation (load/store, control/branch-jump, computational, no operation), and is used when constraints need to apply to a group of operations or decisions need to be coordinated across operations of the same class.

When transaction-level fields alone are not descriptive enough, additional properties are added. For the MIPS branch-on-equal operation (BEQ) — "if the contents of general register rs and rt are equal, the branch is taken and the program execution jumps to a branch label; the jump address is computed to the program counter (PC) calculated as the current PC plus a sign extended immediate value, or PC = PC + sext(imm)" — the opcode class is extended as follows:

• A LABEL value is added to the enumerated operation type kind_e.
• A label_suffix property is added, where the suffix is an integer representing a line number in a program trace listing (e.g., LABEL_005 is the 5th line in the sample program trace).
• from and to properties are added. With the sample trace, the BEQ that jumps from line 3 to line 5 has from = 3 and to = 5.

The relative program counter offset (the imm field of the operation encoding) is then calculated from these two integral numbers, which keeps labels unique in legal program traces.

ISA information in processor verification

Constrained-Random Verification (CRV) of processors requires a stimulus-generation infrastructure built with sufficient knowledge of the processor's instruction set architecture and state. Pure random instructions rarely create useful stimulus for important design functionality such as branches, jumps, and exceptions; CRV can only do so when the infrastructure is built with enough intelligence about the ISA.

RISC-V coverage groups

The cross-level processor-verification evidence uses ISA analysis to define coverage points for randomized instruction streams. By analyzing the RISC-V specification, the authors identified six important instruction groups that act as the basis for coverage points: Arithmetic, Control Flow, Memory, Special & System, Control & Status Register (CSR), and Other.

An instruction group covers a set of instructions, such as arithmetic instructions or load/store instructions. Coverage points are defined as the cross-product of instruction groups, so functionality can be tested in combination with every other function; with six groups this yields 36 coverage points.

The groups are populated from RISC-V subsets and instruction types as follows:

• Arithmetic includes arithmetic instructions from RV32I and RV32C and all instructions of RV32M.
• Control Flow includes the unconditional jump and conditional branch instructions of RV32I and RV32C.
• Memory includes the load/store instructions of RV32I and RV32C and the memory-ordering instructions of RV32I.
• Special & System includes the ECALL, EBREAK, NOP, and HINT instructions of RV32I; the illegal, NOP, breakpoint, and HINT instructions of RV32C; and the FENCE instruction of ZIFENCEI.
• CSR is equivalent to ZICSR.
• Other includes instructions from undefined and unsupported subsets and the privileged architecture.

Coverage-guided randomized instruction streams

The verification approach uses endless randomized instruction stream generation with Coverage-guided Aging. Random instruction generators are initialized with the same cryptographic seed value so that separate generators provide the same endless randomized instruction stream. Some instructions are first generated and executed by the instruction-set simulator; the RTL processor then fetches its instruction stream, with a core adapter handling microarchitectural details such as pipelining, prefetching, and fetch-buffering.

At run time, a Coverage-Observer watches executed instructions and matches them to coverage points. When an instruction sequence covers a point, the observer sets the corresponding Coverage-guided Aging counter to a defined maximum. The counter is periodically decremented, and when it reaches its minimum, the observer gives a hint to the Instruction-Injector consisting of a random instruction sequence needed to cover that point. The instructions are randomly selected from the instructions sampled in the current run. The Coverage-Observer resets the counter if the groups are covered again.

The Instruction-Injector injects instruction sequences into the random test generators in compliance with their internal state. If instruction injection ignores the internal state, the generators provide differing instruction streams that may lead to a false result of the Comparator. To achieve a legal injection, the Instruction-Injector measures how many instructions have executed before the current state of the random generator was reached, and then schedules the injection to the same near-future instruction count for all instruction generators. This approach is valid because deterministic random sources initialized with the same seed value provide the same random sequences.

In the case study, the Coverage-guided Aging counter is configured to the value 100 and is decremented after a new instruction is generated, so that 36 coverage points are triggered frequently while enough random instructions are produced for coverage.

RISC-V testability advances

A dedicated testability survey organizes recent advances in RISC-V testability into five key areas: AI-driven and fuzzing-based test generation, statistical fault injection for security assessment, system-level test innovations, design-for-test (DfT) architectures, and hardware-software co-verification. These developments collectively enhance the ability to verify, validate, and test RISC-V processors across the design lifecycle, from pre-silicon verification to post-silicon debug and manufacturing test.

AI-driven and fuzzing-based test generation

Building on earlier constrained-random algorithm approaches, machine learning techniques have been applied to test pattern generation for RISC-V processors. The survey notes that "verification of RISC-V processors has also developed on coverage-driven instruction generation techniques." Coverage-driven methods systematically explore the instruction space to maximize functional coverage and uncover corner-case behaviors.

Chen et al. introduced a deep reinforcement learning framework that generates instruction sequences maximizing toggle coverage while minimizing test time; their approach achieved 95.4% average coverage across various benchmarks.

Differential fuzzing approaches, such as DifuzzRTL, have also been applied to RISC-V RTL designs, allowing the comparison of multiple implementations under identical instruction sequences to identify inconsistencies.

Statistical fault injection for RISC-V security

The methodology for security assessment of the RISC-V ISA has evolved from ad-hoc testing to sophisticated, simulation-based statistical fault injection (SFI). This evolution directly addresses the need for scalable, reproducible vulnerability analysis in an open ecosystem of diverse hardware implementations. Early security evaluations of RISC-V were limited to physical hardware testing, which lacked the fine-grained control and observability necessary for deep, root-cause analysis of microarchitectural vulnerabilities.

A pivotal shift occurred with the development of specialized simulation frameworks. The gem5-MARVEL framework tracks fault propagation across cores and coherent memory, enabling the statistical injection of transient, intermittent, and permanent fault models under highly configurable and repeatable conditions.

The most recent evolution seeks to bridge the gap between simulation flexibility and hardware timing accuracy through hardware-accelerated platforms. The FPGA-based Chiffre platform enables real-time fault injection into RISC-V cores synthesized on adaptable hardware, providing a scalable toolkit for statistically rigorous security evaluation.

System-level test innovations

System-level testing for RISC-V processors and SoCs has advanced significantly to address the challenges of functional verification, compliance, and integration validation across simulation, emulation, and silicon environments. Randomized instruction sequence generation and constrained-random stimulus tools, such as Synopsys STING, produce test programs that exercise privilege levels, memory protection, interrupt handling, and other system behaviors in a portable, self-checking manner across simulation, FPGA prototypes, and silicon platforms. These generated tests have been effective at uncovering corner cases such as cache coherence conflicts and fence instruction mishandling that directed tests often miss.

The RISC-V community also standardizes randomized instruction testing frameworks like TestRIG, which uses RVFI-DII interfaces to drive random instruction streams against both reference models and implementations under test, comparing execution traces to detect divergences early in development. TestRIG's approach supports rapid iteration and debugging, and has been applied to validate ISA extensions such as capability architectures.

Comprehensive system-level verification suites are provided by commercial and open-source efforts, such as Breker's RISC-V SoCReady SystemVIP test suite, which synthesizes coverage-driven tests for complex operations, including multicore coherency, atomic instructions, paging, interrupts, system memory protection, and performance profiling. SystemVIP's portability across simulation, emulation, prototype, and post-silicon phases enables unified validation across the design lifecycle.

Open-source directed test frameworks like RiESCUE further facilitate customizable test generation and compliance testing with support for multiple RISC-V extensions, self-checking test harnesses, and flexible constraints.

Design-for-test (DfT) architectures

Design-for-Test support is critical for ensuring manufacturability and correctness of complex RISC-V SoCs. Traditional scan-chain techniques and built-in self-test (BIST) remain foundational, but recent research has adapted and evaluated these methods in the context of highly configurable RISC-V designs. Scan-based DfT remains relevant for RISC-V cores, enabling sequential element controllability and observability during test shifts, which supports automatic test pattern generation (ATPG) for structural faults such as stuck-at and transition faults.

Functional and compliance verification frameworks for RISC-V benefit from constrained random and reference-model-driven testing, which augment classical DfT by exercising ISA-defined behaviors in simulation and emulation environments:

• Qiu and Liu propose an integrated UVM-TLM co-simulation framework that co-verifies functional correctness alongside performance models for superscalar RISC-V cores, effectively bridging between high-level verification and structural test validations.
• Galimberti et al. describe functional ISS-driven verification that interfaces a RISC-V instruction set simulator with RTL testbenches to achieve high coverage across pipeline and control flows.
• For RISC-V vector and ISA extension units, Lai et al. develop an instruction coverage analysis methodology based on TSVC (Test Set Vector Coverage) to systematically quantify RVV (RISC-V Vector Extension) coverage, forming the basis for improved test suite design that captures complex vector behaviors.

Hardware-software co-verification

Hardware-software co-verification plays a central role in ensuring that RISC-V implementations correctly realize the instruction set architecture and interact safely with system software.

Formal verification. Formal verification approaches have been applied to RISC-V cores to prove ISA compliance and functional correctness at varying abstraction levels. Polynomial Formal Verification (PFV) techniques use Binary Decision Diagrams (BDDs) and related structures to bound verification complexity and have been demonstrated on multi-cycle RISC-V cores covering both combinational and sequential logic. These methods provide mathematical guarantees of correctness, complementing traditional dynamic verification.

Symbolic execution and co-simulation. Bruns et al. integrate symbolic execution engines such as KLEE with co-simulation frameworks that couple an instruction set simulator (ISS) with the RTL of a RISC-V processor under test, allowing symbolic exploration of both hardware and software paths and revealing subtle mismatches between simulation and RTL behavior.

Hybrid co-verification. FPGA-assisted emulation frameworks like FERIVer accelerate RTL verification by cross-validating hardware behavior against software models running on the same platform, achieving orders-of-magnitude speedups while preserving functional correctness checks. Unified co-simulation infrastructures using UVM and SystemC/TLM provide scalable environments where software workloads drive hardware models, enabling early detection of integration and performance issues across design iterations.

riscv-formal. The RISC-V formal verification ecosystem also includes open frameworks such as the riscv-formal project. This framework is widely used to express properties and formally check RTL models against reference ISA specifications using the RISC-V Formal Interface (RVFI), often as part of hybrid verification flows that mix formal, simulation, and co-simulation components.

Open RISC-V platforms and timing behavior

Open-source RISC-V platforms such as PULP (Parallel Ultra-Low Power) provide lightweight in-order cores (e.g., RI5CY) with simplified pipelines and predictable execution characteristics. These cores are frequently used in safety-oriented embedded contexts due to their reduced microarchitectural complexity and analyzable timing behavior.

The Rocket and BOOM RISC-V cores provide openly documented microarchitectural implementations that have enabled systematic study of speculation and timing behavior. While BOOM is an out-of-order speculative processor, its open RTL description allows researchers to selectively disable speculation, configure cache hierarchies, and evaluate timing interference under controlled conditions. This transparency facilitates experimental assessment of temporal isolation mechanisms, and experimental evaluation demonstrates analyzable execution latency across vector workloads without reliance on speculative mechanisms.

Recent analyses of speculative execution in RISC-V cores have shown that transient execution behavior can affect timing predictability. Although speculative attacks were first demonstrated on x86 and ARM, subsequent studies confirm that similar transient behaviors can manifest in speculative RISC-V microarchitectures.

Specialized ISAs for accelerators

A public context entry introduces an ISA for processing-in-memory (PIM) deep neural network accelerators. The proposed ISA targets DNN inference on PIM-based architectures where the trained weights have already been programmed into the accelerator and remain fixed during inference. The target DNNs include convolutional neural networks (CNNs) and multi-layer perceptrons (MLPs).

The proposed ISA is transparent to both applications and hardware implementations, and is intended to enable unified toolchains for PIM-based DNN accelerators and software stacks. For practical hardware that uses a different ISA, the instructions generated by the unified toolchain can be converted to the target ISA.

Popular devices used to build PIM-based DNN accelerators include resistive random-access memory (RRAM), flash, ferroelectric field-effect transistor (FeFET), and static random-access memory (SRAM); the proposed ISA does not restrict the underlying device. The ISA has been used in the open-source DNN compiler PIMCOMP-NN and the open-source simulator PIMSIM-NN.

Cross-ISA software portability

A second public source addresses software portability across instruction set architectures. During migration across ISAs, software package build repair is a critical task for ensuring the reliability of software deployment and the stability of modern operating systems. The benchmark introduced in that work comprises 268 real-world software package build failures across diverse architectures and languages, and provides a standardized evaluation pipeline for evaluating language models on cross-ISA build repair. The results show that cross-ISA software package repair remains difficult and requires further advances.

Practical role

Across the provided evidence, ISA information serves several practical roles. First, it names and structures processor capabilities, as in RISC-V base ISAs plus extensions, and defines functional classes such as MIPS-I's four operation categories. Second, it provides the basis for verification tooling: CRV systems can classify executed operations, define coverage points, drive random instruction generation, and inject targeted instruction sequences while keeping instruction streams consistent across instruction-set simulators and RTL cores. Third, specialized ISAs (such as the PIM DNN accelerator ISA) abstract over device-level differences so that unified toolchains and software stacks can be developed, and the same ISA can serve as a unit of portability across heterogeneous hardware targets. Fourth, the ISA is the target of testability research: AI-driven test generation, statistical fault injection, system-level testing, design-for-test architectures, and hardware-software co-verification all aim to confirm that implementations faithfully realize the ISA specification. Finally, the ISA is the unit at which software portability must be addressed, motivating benchmarks for cross-ISA build repair.