Overview

An extended ISA trace log is an ISA-simulation trace whose per-instruction entries are augmented with the values of a selected subset of control and status registers (CSRs). In ProcessorFuzz, the log is generated by extending the Spike open-source RISC-V ISA simulator so that its existing trace logic also stores monitored CSR values after each committed instruction. The reported instrumentation cost is 0.4% in lines of C++ code and 0.15% in runtime overhead. [C1][C2]

Figure 4 of the paper shows a concrete example. For each executed instruction the log records the program counter, the disassembled instruction, and a bracketed tuple that lists the monitored CSR values in a fixed order. In the paper's example that order is mstatus, mcause, scause, medeleg, frm, fflags, with each value rendered in hexadecimal and split into a "Privileged" group and an "Unprivileged" group (which contains frm and fflags). Concretely the excerpt reads:

CSR changes are color-coded in the figure: red for mstatus transitions and blue for fflags transitions. The paper uses the sret at line 1 to illustrate how a CSR transition is identified: comparing the entries in lines 1 and 2 of the "Privileged" column shows the mstatus value changing from ...006000 to ...006020. [C2][C3]

The log is the central artifact of ProcessorFuzz's feedback loop: the Transition Unit takes the extended ISA trace log as its first input, and the trace is later compared against an extended RTL trace log (produced by Verilator-based RTL simulation) when a candidate bug is investigated. [C1][C2]

Why augment the ISA trace with CSRs

An ISA simulator already produces a fast execution trace, but a plain trace does not directly expose architectural state changes that are useful for coverage. The paper motivates using CSRs because they are the system registers in an ISA specification used to control the processor (e.g., delegated exceptions) or to hold information about the current architectural state (e.g., the state of the floating-point unit). CSRs have direct control over the current processor state, and a value change in a CSR often signifies an architectural state change such as a value change in a CSR that stores an exception code or a privilege level. Projecting CSR values into the trace therefore turns the trace into a record of how the architectural state evolves during execution. [C3][C4]

Using the ISA simulator (rather than the RTL) for this step brings two further benefits reported in the paper: it is much faster, with the RISC-V Spike ISA simulator measured to be on average 79× faster than the RTL simulation of the RISC-V BOOM processor, and it is much easier to instrument, because the simulator's existing trace logic can be extended with the selected CSRs without touching any hardware description. A single instrumented ISA simulator can be reused across any processor design targeting the same ISA. ProcessorFuzz reports 0.4% instrumentation overhead in lines of C++ code and 0.15% runtime overhead in the ISA simulator, compared with the higher overheads of prior RTL-instrumented fuzzers (71% in TheHuzz and 97% in RFUZZ). [C1][C2][C3][C4]

Role in CSR-transition coverage

ProcessorFuzz monitors CSR transitions rather than only unique CSR values. A CSR transition is a change of one or more monitored CSRs between two consecutive points in the trace. The paper motivates transition-based coverage with bugs that depend on a transition from one abstract state to another: if both endpoint states have already been covered individually, a state-only coverage metric may not prioritize the input that exercises the specific transition. Monitoring transitions can therefore increase feedback sensitivity, analogous to software fuzzers that track edges rather than only basic blocks. This is in contrast to DIFUZZRTL's register coverage, which for each newly covered FSM state only stores the current state of the processor and does not consider the previous one. [C3]

The Transition Unit's full pipeline, shown in Figure 6 of the paper, takes the extended ISA trace log as its input and proceeds in five stages: Extract Transitions, Filter Transitions, Group Transitions, Check Transition Map, and New Transition?. The transition map is empty at the beginning of a fuzzing session and maintained throughout the session. Once tuples are created from a trace, the map is queried to check whether each detected transition is new or a duplicate. Tuples that contain new transitions are added to the map and the current test input is marked as interesting. [C1][C2]

Extracting transitions

In the extraction stage, every monitored CSR change observed in the extended ISA trace log is turned into a tuple. Each tuple additionally records the instruction mnemonic of the instruction that produced the change. The paper explains that the mnemonic is included because the same transition can be triggered by different instructions: for example, both fdiv.s (floating-point division) and fsqrt.s (floating-point square root) can trigger the same transition in the fflags CSR in RISC-V through an invalid-operation event, yet only one of them (e.g., fdiv.s in the paper's Bug 2) may actually contain a bug. Tagging each transition with its triggering mnemonic therefore uniquely identifies transitions triggered by different instructions. Only the mnemonic is recorded, not the operands, so that repetitive transitions triggered by different operands of the same instruction are not counted as distinct. [C1][C2]

Filtering transitions

The number of possible CSR transitions can be large depending on the cumulative width of the selected CSRs, and not all of them represent interesting architectural-state changes. The paper gives the example of legal writes to status CSRs such as RISC-V mstatus, which may not be relevant for processor testing. A filter is therefore applied to the transitions extracted from the extended ISA trace log to drop such unnecessary transitions before they are stored in the transition map. [C1][C2]

Grouping transitions

To separate concerns across processor subsystems, the implementation discussed in the paper groups transitions by CSR family. In particular, transitions for frm and fflags are placed in a dedicated group so that floating-point CSR transitions are stored separately from transitions of the other monitored CSRs. [C1][C2]

CSR selection

The extended ISA trace log does not need to include every CSR. The paper notes that an ISA may define many CSRs — RISC-V defines up to 4096 — and monitoring all of them can mislead the fuzzer because not every CSR provides distinctive information about processor state. For example, monitoring the RISC-V instret CSR would create a transition for every committed instruction, making nearly every test input appear interesting. [C1][C2]

The monitored CSR set is drawn from the system's privileged and unprivileged register groups. The paper's CSR table labels examples such as mscratch (holds a pointer to the machine-mode context space while the hart executes in a lower privilege mode), {m,s}epc (contains the PC of an instruction that caused an exception for machine or supervisor mode), and sscratch (holds a pointer to the supervisor-mode context space while the hart executes in user mode) as relevant privileged CSRs to consider for monitoring. [C2]

The monitored CSR set can be further targeted to a verification goal. The paper states that if the target processor does not support interrupts within the testing framework, any CSRs related to the configuration or status of interrupts can be excluded. Similarly, if the goal is to verify floating-point functionality, only floating-point CSRs can be monitored; in the implementation discussed in the paper, transitions for frm and fflags were separated to distinguish floating-point operations from the rest of the CSRs. [C1][C2]

Use in the ProcessorFuzz workflow

ProcessorFuzz has two main implementation steps related to the extended ISA trace log: generating it using the ISA simulator, and consuming it in the Transition Unit. In the reported implementation, Spike was extended to store monitored CSR values, with 0.4% instrumentation overhead in lines of C++ code and 0.15% runtime overhead. The same mutation engine as in DIFUZZRTL's open-source repository is used, so that the comparison isolates the coverage feedback mechanism (CSR-transition coverage vs. register coverage) from the input-generation mechanism. For the RTL simulation of all processor designs, Verilator, an open-source RTL simulator, is used. [C1][C2]

The full ProcessorFuzz design (Figure 3 of the paper) places the extended ISA trace log at stage 4 of the flow: an input from the mutation engine is run on the ISA simulator, which emits the extended ISA trace log; the Transition Unit (stage 5) extracts CSR transitions, checks the transition map, and either adds new ones to the map (marking the test input as interesting) or discards the input. [C2]

When the Transition Unit determines that an input produces a unique CSR transition, ProcessorFuzz launches RTL simulation (stage 6), which generates an extended RTL trace log containing the same kind of CSR information as the extended ISA trace log. The two logs are then compared (stage 7): any difference between them is treated as a potential processor-design bug requiring further investigation by a verification engineer, usually by manual inspection. If the input does not produce a unique transition, ProcessorFuzz discards it and continues to the next fuzzing iteration. [C2]

In the evaluation reported in the paper, ProcessorFuzz is applied to three real-world open-source RISC-V processor designs (Rocket Core, generated via the Rocket Chip SoC Generator framework, the RISC-V BOOM processor, and a third design), with Spike also used as a reference model for verification. [C1]