This means FetchStage should now behave in the same way with RVFI-DII as
with an I-Cache. A Dii_Parcel_Id is fed alongside PC everywhere relevant
and follows very similar logic, but, importantly it's just extra state
on the side, it doesn't affect what we do with the branch predictor and
parcel combining/instruction decoding logic.
In particular, the previous set of debug info only looked at one of the
superscalar ways, assuming the 0th was always the next instruction, but
there's a level of indirection to map ports to ways that was missed. But
now we dump out both ways and more. And yes, I fully recognise the
atrocity that is the type in use here... please forgive me. It doesn't
help that bsc is buggy and gets confused about the structure of nested
tuples[1].
Drops the commit debug output to only the low 32 bits of PCC's address
and no instruction bits; as this has been committed it should be (and
has always been observed to be) within bounds and, thus, fit in 32 bits
when running in M-mode, with the instruction bits obtainable from the
binary. I'd much rather know about potentially-dodgy speculative
addresses than things we can reliably infer given the limited number of
DMI registers free (though we could hijack other encodings if
necessary).
[1] https://github.com/B-Lang-org/bsc/issues/199
When DEBUG_WEDGE is defined, expose the last committed and next in the
reorder buffer PC and corresponding instruction via DMI registers, since
even when the core is wedged and we can't read GPRs etc we can still
interact with the debug module itself. Hopefully this proves useful for
debugging wedges.
When a CSRRx instruction writes to FCSR/FFLAGS/FRM, the CPU also
changes MSTATUS.FS and, by implication, MSTATUS.SD because the
floating point state has become "dirty". Tandem Verification
trace-generation was not reporting this update.
src_Core/CPU/CsrFile.bsv
Various fixes for WARL'd values of mstatus and sstatus, medeleg,
Added tval field in Trap_Updates returned by csrf.trap
src_Core/Core/Trace_Data2.bsv
Added fields for store_data and store_data_BE
src_Core/Core/Trace_Data2_to_Trace_Data.bsv
Added treatment of store_data and store_data_BE
Fixed bug in next_pc for mkTrace_RET
src_Core/RISCY_OOO/procs/RV64G_OOO/CommitStage.bsv
Fixed Trace_Data2 struct to TV for pc in case of xRET, and tval in case of trap
src_Core/RISCY_OOO/procs/RV64G_OOO/MemExePipeline.bsv
Added store_data and store_data_BE in calls to rob_setExecuted_doFinishMem
src_Core/RISCY_OOO/procs/lib/ReorderBuffer.bsv
Added store_data and store_data_BE in methods rob_setExecuted_doFinishMem
Now handling all Alu and Fpu pipeline outputs, traps and xRets.
Still todo:
(1) Mem pipeline outputs (Ld, Lr/Sc, Amo outputs to dest reg)
(2) For CSRRx, currently reporting WARL pre-write updates; needs to be WARL'd update.
Rd value (destination register) of Integer ops supported
Trap updates (priv and CSR updates) supported.
Still pending: Memory ops Rd value, Fpu Rd value
Now able to run multiple ISA tests in a single simulation run
connected to remote debugger DSharp, using either hart_reset or
ndm_reset between tests to bring the system back into reset state.
All Debug Module commands working:
- dm_reset, hart_reset, ndm_reset
- break (set breakpoint)
- step
- continue (until breakpoint of 'halt' command)
- halt
- read/write GPR, FPR, CSR, memory
- elf_load
After a test, GDB can write DCSR to restore to Machine privilege,
write to PC (DPC) to restore boot value,
write MSTATUS to restore to initial value,
then can load and run next test.
Stop, set breakpoint: working, stopping successfully.
Step: working: stops after a step.
Continue (resume) working after Stop and Step, but not after stop by breakpoint (needs debugging)
Read/Write GPRs, FPRs, CSRs, memory working.
