Overview

In the ProcessorFuzz workflow, the Transition Map (TM) records CSR transitions that have already been observed during a fuzzing session. After the Transition Unit creates tuples for detected transitions, it queries the map to determine whether each transition is new or a duplicate. Tuples representing new transitions are added to the map, and the corresponding test input is marked as interesting. The transition map starts empty at the beginning of a fuzzing session and is maintained throughout the session.

Role in ProcessorFuzz

The Transition Map is used by the Transition Unit. The Transition Unit takes an extended ISA trace log as input and communicates with the TM to decide whether the trace contains any new transitions. This decision drives ProcessorFuzz's downstream execution:

1. The Transition Unit extracts CSR transitions from the extended ISA trace log.
2. ProcessorFuzz filters out transitions that are not useful for testing-relevant architectural state changes.
3. The Transition Unit queries the Transition Map to check whether the remaining detected transitions have been seen before.
4. If a unique CSR transition is found, ProcessorFuzz launches RTL simulation, generates an extended RTL trace log, and compares it against the extended ISA trace log.
5. If no unique transition is found, ProcessorFuzz discards the input and continues with the next fuzzing iteration.

Why track transitions instead of states

ProcessorFuzz uses CSR-transition coverage rather than only tracking unique CSR values. The paper motivates this by noting that state-only coverage can miss behavior that depends on the previous state. In the described example, a bug triggers in state N2 only if the previous state was N1; if N1 and N2 have already been covered individually, a state-only metric would not reward the transition from N1 to N2. By monitoring transitions, ProcessorFuzz can detect that transition as new even though both endpoint states were already observed.

The authors compare this rationale to software fuzzers that monitor program edges rather than only basic blocks: the transition captures ordering information that individual states do not.

Filtering and CSR selection

The usefulness of the Transition Map depends on which CSR transitions are admitted into it. ProcessorFuzz does not treat every CSR value change as equally useful. The paper states that monitoring all available CSRs can mislead the fuzzer because some CSRs do not provide distinctive information about the processor state. For example, monitoring instret, which holds the total number of retired instructions, would cause every committed instruction to appear as a transition, making nearly every test input appear interesting.

ProcessorFuzz also filters transitions caused by writes to status CSRs when those transitions do not affect the architectural state in a way relevant to processor testing. The paper gives mstatus in RISC-V as an example of a status CSR whose legal writes may be overwritten later by updated status.

Relationship to RTL checking

The Transition Map is part of the coverage-feedback path, not the final correctness oracle. When a test input produces a unique CSR transition, ProcessorFuzz uses that signal to run RTL simulation and compare the extended RTL trace log with the extended ISA trace log. A difference between the two logs is treated as a potential processor-design bug that requires investigation by a verification engineer.