search

CHERIoT-Platform / cheriot-sail

Sail code model of the CHERIoT ISA
Other
34 stars 9 forks source link

Extending support for DII execution mode #24

Open kliuMsft opened 10 months ago

kliuMsft commented 10 months ago

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 #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 commented 10 months ago

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

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 commented 10 months ago
  1. 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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago
  • "No support for RV32E" can be worked around by just commenting out the high register selector values

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