CSR (Control and Status Register)

In the supplied RISC-V processor-verification evidence, CSR denotes the RISC-V Control and Status Register: architectural state defined by the RISC-V ISA together with the special instructions used to access it. [C1] The acronym is consistently used in this ISA sense across the mutation-based compliance testing, Ibex co-simulation, and ProcessorFuzz sources; the public context entries that use "CSR" for Corporate Social Responsibility and "CSRS" for a code-search model are unrelated and are not the subject of this article. [P1][P2]

RISC-V ISA definition of CSRs

The mutation-based Compliance Testing (CT) paper, in its RISC-V background section, states that the RISC-V ISA "defines CSRs (Control and Status Register) and special instructions to access them," and that the CT framework in that work currently focuses on the base RV32I ISA without yet covering CSRs. [C1] Identifying CSRs and additional RISC-V extensions as the first step of future work, the paper writes: "One of the first steps would be to consider CSRs and additional RISC-V extensions. By leveraging our existing mutation classes and framework, it should be straightforward to integrate additional RISC-V extensions with our approach." [C2]

The same paper notes that CSR setup is also a prerequisite for higher-level features. It specifically observes that virtual memory support "requires setting up the CSRs to activate virtual memory support" and that page tables must additionally be configured in memory, which makes automated CSR coverage important for future MMU testing. [C3]

CSRs as a fuzzing coverage signal (ProcessorFuzz)

ProcessorFuzz is a hardware fuzzer for RTL processor designs whose distinguishing feature is that it "guides the fuzzer with a novel CSR-transition coverage metric." [C7] The rationale given is that "CSRs are in charge of controlling and holding the state of the processor," so "transitions in CSRs indicate a new processor state," and using these transitions as feedback enables ProcessorFuzz to explore new processor states. [C7]

Two additional properties follow from this design choice:

HDL-agnostic monitoring. Because ProcessorFuzz monitors CSR transitions externally rather than instrumenting the design, "ProcessorFuzz is agnostic to the HDL and does not require any instrumentation in the processor design," and "thus, it supports a wide range of RTL designs written in different hardware languages." [C7]
Evaluated on real-world open-source cores. ProcessorFuzz was evaluated on three RISC-V cores — Rocket, BOOM, and BlackParrot — where it "triggered a set of ground-truth bugs 1.23× faster (on average) than DIFUZZRTL" and "exposed 8 new bugs across the three RISC-V cores and one new bug in a reference model," with all nine bugs confirmed by the corresponding project developers. [C7]

This CSR-transition metric is the technique on which ProcessorFuzz depends for its coverage guidance, and is the only technique-related entry related to CSR in the supplied evidence.

Role in RISC-V co-simulation

Dromajo is described (in earlier, related evidence preserved from the previous version of this article) as an emulator for co-simulation with RTL processors implementing the RISC-V RV64GC instruction set. Its verification flow can generate checkpoints from a RISC-V ELF binary and then load those checkpoints into both Dromajo and an RTL model so that the two models begin with identical architectural state. CSRs are part of this checkpointed architectural state, so CSR contents are part of what must match during co-simulation. [C4]

The Micro 2021 evaluation reports that Dromajo alone found nine bugs across the evaluated RISC-V cores, while Dromajo enhanced with Logic Fuzzer exposed thirteen total bugs using the same listed tests. [C5] Several of the reported divergences are CSR-related.

CSR-related bugs in the evidence

Several reported bugs involve incorrect CSR behavior (preserved from the prior version of this article, supported by earlier evidence on Dromajo co-simulation):

dcsr / dpc debug behavior (CVA6, Bug B1): A CVA6 bug involved incorrect update logic for the debug control status register. After dret, execution should jump to the PC indicated by the dpc CSR and resume in the privilege mode indicated by the prv bits in the dcsr CSR. Dromajo exposed a divergence where it resumed in user mode while CVA6 resumed in machine mode; the designer attributed the confusion to the requirement that the core update the prv bits to the current running privilege level when entering debug mode. [C5]
stval trap information (Bug B3): The evidence states that, according to the RISC-V ISA, stval is written with exception-specific information when the processor traps into supervisor mode. Dromajo caught a mismatch when reading stval inside the exception handler because the implementation set it incorrectly. [C5]
mtval trap information (Bug B13, BOOM): A BOOM bug was exposed when a random instruction stream caused Dromajo to flag a mismatch while reading the mtval CSR. The fault was expected to set mtval to the address of the instruction that caused the exception, but the value read from BOOM was off by 2; the evidence attributes this to handling of compressed RISC-V instructions (RVC) and misaligned-instruction exceptions, and notes that the bug disappears in later BOOM commits. [C6]
mepc on BOOM traps (Bug B13): The same BOOM scenario references the mepc CSR being set to 0x196 during a setup code path that ended in an mret instruction, which then faulted and led to the mtval mismatch. [C6]

These cases show that CSR correctness is not limited to storage of register values; it also includes correct interaction with traps, debug return, privilege state, exception handlers, and compressed-instruction behavior. [C5][C6]

CSR verification under external stimulus (Ibex)

The Ibex verification documentation describes a different verification challenge for CSRs: scenarios involving external stimulus such as interrupts and debug requests. [C4]

Standard RTL/ISS trace-log comparison collects register writeback information from both the core and the golden-model ISS and checks that the core wrote the correct data to the correct registers in the correct order. This works for ordinary execution but breaks down when external stimulus is involved, because ISS models can simulate traps due to exceptions but cannot model traps due to external stimulus. [C4]

To verify that the core has entered the proper interrupt handler, entered Debug Mode properly, and updated any CSRs correctly under external stimulus, the Ibex flow uses the handshaking mechanism provided by the RISCV-DV instruction generator. This mechanism allows the core to send status information to the testbench during program execution for any analysis required to increase verification effectiveness. The signature address used by the Ibex testbench for this handshaking is 0x8ffffffc. [C4]

A modified trace-log comparison complements the handshaking mechanism. Because the ISS trace log will not contain any execution information in the debug ROM or in any interrupt handler code, comparing every register write performed during the entire simulation would yield incorrect results. Instead, only the final values contained in every register at the end of the test are compared against each other, since any code executed in the debug ROM and trap handlers should not corrupt register state in the rest of the program. [C4]

The handshaking mechanism is extensively used in the Ibex test environment to provide runtime verification for situations involving external debug requests, interrupt assertions, and memory faults. [C4]

CSRs as future work for mutation-based compliance testing

The mutation-based CT paper limits its current evaluation to mutations in the execution unit for the base RV32I ISA and explicitly identifies CSRs and additional RISC-V extensions as the first step of future work. [C1][C2] The motivation is twofold:

Direct CSR coverage: the paper proposes to consider CSRs and additional RISC-V extensions by leveraging the existing mutation classes and framework, and additionally suggests producing a minimized test-suite that still kills all mutants, which the authors note would be particularly helpful as the number of test-cases grows with each new extension. [C2]
Prerequisite for MMU testing: the paper highlights that virtual memory (typically done by an MMU) "requires setting up the CSRs to activate virtual memory support" along with page tables in memory, and that page tables must be arranged to reach a specific mutation, making comprehensive and automated MMU testing a natural downstream use of CSR coverage. [C3]

The paper also documents a mutation-engineering caveat relevant to CSR-adjacent code: some mutants cannot be killed in a platform-independent way because they rely on a very specific (hardcoded) memory address or PC value, and the existing CT framework allows each RISC-V simulator to define its own memory layout via a custom linker script. [C3] The suggested remediation is to leverage virtual memory and re-map physical sections, which again depends on CSR support. [C3]

Practical interpretation

Within the provided evidence, CSR verification and validation is best understood through four complementary views:

Architectural-state comparison (Dromajo co-simulation): CSRs are part of architectural state that must match between the reference model and the RTL implementation. CSR-related bugs were detected when the reference model and RTL implementation disagreed on values such as dcsr, stval, mtval, or mepc, or on the privilege behavior implied by CSR contents. [C4][C5][C6]
Runtime status reporting under external stimulus (RISCV-DV handshaking): When the ISS cannot model traps from external stimulus, the handshaking mechanism is used to verify that the core correctly updates CSRs and enters the right exception/debug handlers, with trace-log comparison limited to final register values. [C4]
Coverage/fuzzing signal (ProcessorFuzz CSR-transition metric): CSRs can also be observed from outside the RTL — without HDL-specific instrumentation — to drive a coverage-guided fuzzer. Monitoring CSR transitions provides a feedback signal correlated with new processor states, and on Rocket, BOOM, and BlackParrot this approach reached ground-truth bugs faster than DIFUZZRTL and exposed eight new core bugs plus one reference-model bug. [C7]
Target of future compliance testing (mutation-based CT): The mutation-based CT framework is positioned to extend from base RV32I to CSRs and additional extensions, both as a direct coverage target and as a prerequisite for comprehensive automated MMU testing, and is expected to leverage its existing mutation classes. [C1][C2][C3]

Evidence limitations

The supplied evidence does not define the full CSR address map, CSR encodings, access permissions, or all RISC-V CSR semantics. It supports only the verification- and fuzzing-oriented views summarized here: CSRs are architectural state in RISC-V cores defined by the ISA together with the special instructions used to access them; they are included as part of the architectural state compared in Dromajo-style co-simulation; they are a target of interest for future mutation-based compliance testing; they require special runtime status reporting (the RISCV-DV handshaking mechanism) when verifying behavior under external stimulus; and, in ProcessorFuzz, the externally observed transitions between CSR values form the coverage signal that drives the fuzzer.