CSR

In the supplied RISC-V processor-verification evidence, CSR is used for RISC-V control status registers. CSRs are treated as part of the processor architectural state: Dromajo checkpoints include registers, CSRs, memory, interrupt state, and performance counters. [C1]

Role in RISC-V co-simulation

Dromajo is described 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. Because CSRs are included in the checkpointed architectural state, CSR contents become part of the state that must match during co-simulation. [C1]

The evidence shows Dromajo finding CSR-related divergences by comparing architectural behavior between the reference model and the hardware implementation. 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. [C2]

CSR-related bugs in the evidence

Several reported bugs involve incorrect CSR behavior:

• dcsr / dpc debug behavior: 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. [C2]
• stval trap information: 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. [C3]
• mtval trap information (CVA6): A similar CVA6 issue involved mtval, where the control status register was written with an incorrect value. [C4]
• mtval on BOOM traps: 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 and misaligned-instruction exceptions. [C5]
• mepc on BOOM traps: The BOOM scenario also 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. [C5]

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. [C2][C3][C5]

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. [C7]

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. [C7]

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. [C7]

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. [C7]

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. [C7]

CSR stress in broader test-generation flows

The supplied STING evidence also identifies CSRs as an important RISC-V verification target. STING is described as a bare-metal, software-driven constrained-random RISC-V test generator that produces C++-based random streams and ASM-style directed tests. The evidence says STING-generated programs are portable across simulation, emulation, FPGA prototypes, and silicon, and are architecturally self-checking. It specifically lists CSRs among the areas that STING is effective at stressing, alongside privilege levels, memory protection, and hypervisor extensions. [C6]

Practical interpretation

Within the provided evidence, CSR verification is best understood through two complementary views:

1. 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. [C1][C2][C3][C4][C5]
2. 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. [C7]

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-oriented view summarized here: CSRs are architectural state in RISC-V cores, are included in Dromajo checkpoints, are an important target for constrained-random testing (STING) and directed validation, and require special runtime status reporting (the RISCV-DV handshaking mechanism) when verifying behavior under external stimulus.