Extending support for DII execution mode

[kliuMsft]

The following features when in DII mode are needed in order to use the sail model in the design verification flow.

1. Handling interrupts. If an instruction packet is flagged with an interrupt, the sail model should perform interrupt handling (e.g., update MSTATUS.MIE if interrupt is taken) based on the current MIE status.
2. Similar to Add github action to compile simulator. #1, it's also desirable to be able to model a bus error for the load/store and instruction fetch interfaces. Actually - if we can have a generalized way to make the sail model to talk to a volatile peripheral it would be great.
3. Adding a status-dump pseudo-instruction so that we can dump all architecturally visible registers and use that as a checkpoint against RTL simulation.

[nwf-msr]

I have been able to run some DII/TestRIG tests against the sail model with a handful of hacks in place:

• No support for RV32E CTSRD-CHERI/QuickCheckVEngine#28 can be worked around by just commenting out the high register selector values
• 429055a cuts out the fregs from the rvfi simulator target.

Unfortunately, it is not particularly robust, as might be expected from heretofore untested code. The much less structured random test in TestRIG elicits "Assertion failed: invalid current privilege". I'll raise a separate issue for that.

[nwf-msr]

3. Adding a status-dump pseudo-instruction so that we can dump all architecturally visible registers and use that as a checkpoint against RTL simulation.

That might be tricky... for all the wires that RVFI does define (including all CSRs...), I think it doesn't define shipping out the entire (GP) register file, just those in use by the current instruction. Of course, we can do anything we want, model-wise, to fake it, but it's just... another shortcoming of RVFI.

[kliuMsft]

I see - is the trace generation in sail tied to RVFI? I am hoping we can just dump everything and do a trace file comparison rather than relying on RVFI packets..

[nwf-msr]

I see - is the trace generation in sail tied to RVFI? I am hoping we can just dump everything and do a trace file comparison rather than relying on RVFI packets..

AFAIK yes, there is no existing support for traces other than ad hoc textual printouts and RVFI. It's part of why I was looking at Nexus 5000 last week, because neither of those are very satisfactory answers.

[nwf-msr]

• "No support for RV32E" can be worked around by just commenting out the high register selector values

A better fix is 0c38f6b, which hackishly, but hopefully correctly, models these high selector values as raising illegal opcode traps, rather than crashing the simulator. :)