[dv] Add exception handler to CSR test generator (Fixes #1337)

[RKNAGA18]

Currently, the gen_csr_test.py script generates CSR test assembly that lacks a Machine Trap-Vector (mtvec) initialization sequence. If the generated test attempts an illegal access (such as writing to certain read-only fields), it triggers an Illegal Instruction exception. Without a trap handler configured, the core jumps to 0x0, executing garbage memory until the simulation times out.

Changes

Modified gen_setup() in vendor/google_riscv-dv/scripts/gen_csr_test.py to initialize mtvec.

The trap vector is now explicitly loaded with the address of the existing csr_fail label.

Impact
Illegal CSR accesses that trigger an exception will now be caught by the trap handler, gracefully forcing an immediate test failure rather than hanging the simulator for the duration of the timeout period.

[elliotb-lowrisc]

Hi @RKNAGA18, thanks for looking into this! Do you know if this change would affect testing of the mtvec CSR itself? I'm not especially familiar with "gen_csr_test.py", but it looks like it checks the CSRs against predicted values that are originally derived from the reset values defined in "csr_description.yaml". If these new setup instructions are changing mtvec from its reset value, then I'd expect the first prediction for the value of mtvec to fail.

[RKNAGA18]

Hi @elliotb-lowrisc, because we are explicitly overwriting mtvec with the address of csr_fail right at _start, the hardware state diverges from the YAML reset prediction. Furthermore, since the exact memory address of the csr_fail label is resolved by the assembler/linker at compile time, the Python generator has no way to dynamically calculate the expected value of mtvec to update its internal tracker, guaranteeing a failure on the mtvec reset check. is there any expected approach?

[elliotb-lowrisc]

Hi @RKNAGA18, that's what I was afraid of. I think detecting illegal operations sooner, while useful, can't come at the cost of breaking the ability to test a CSR. Perhaps there is another way to achieve this, although I'm not sure.

You could also try contacting the upstream maintainers, as we "vendor" (import and tweak) this code from: https://github.com/chipsalliance/riscv-dv

[RKNAGA18]

Hi @elliotb-lowrisc, then I'd like to pivot to the first bullet point of Issue #1337 locally. If I modify the Python script's generation logic to properly mask read-only fields so it stops generating the illegal writes in the first place, it should prevent the simulator from trapping and timing out. I will close this PR and open a fresh one once I have the read-only masking logic fixed

[elliotb-lowrisc]

Sure, just keep in mind that any changes will either need to be in the form of a patch file in "vendor/patches/google_riscv-dv" or made upstream, but we can go into the details of that later

[RKNAGA18]

Thanks @elliotb-lowrisc , I will dig into the vendor/patches architecture once I get the read-only masking logic successfully implemented locally.