Each instruction carries its own PC by this point, so it just duplicates
the PC of the first item in the vector. Moreover, when including a
pending straddle at the head, the PC value was not set to the previous
half's, ie PC-2. We keep pred_next_pc as that's used to determine where
the bundle is predicted to go next, and the duplication avoids having to
dynamically index the vector based on the number of instructions fed to
decode.
We should not use a mkRegU for rg_pending_n_items, as otherwise there is
a chance the epochs for rg_pending_f32d happen to match depending on the
uninitialised values. Instead ensure we always reset with no pending
items.
This includes replacing register read values with nullCap if reading x0, which is generally necessary.
This is more-or-less using a new mechanism which shouldn't actually be necessary if the default value in the register file is nullCap.
(In RVFI_DII, we initialise with the almightyCap instead.)
If we never look at the second instruction in the FIFO from the fetch
unit when successfully renaming the first, we do not end up setting
debug_step and thus we will not halt on the next instruction but some
time later. Instead, check for single-stepping at the end of renaming
the first instruction.
This required makeing the Exception type wider by one.
The actual "inBounds" check is currently implemented in the reorder buffer rows, which duplicates the logic ~80 times (number of outstanding instructions), which isn't ideal, but it's using the quick in-bounds check that only compares the mantissa-sized things.
Also move to SetAddrUnsafe, as is traditional for setting the address of PCC where we do proper checks on branches so we really only have the possibility of executing off the end of the length, and therefore cannot become unrepresentable.
This includes renaming Fifo.bsv to Fifos.bsv to account for a case insensitive file system which confuses this library with FIFO.bsv.
Also this includes an update of the verilator flags that are needed for modern verilator.
Finally, some verilator flag changes for building with LLVM.
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.
(1) riscy-ooo was mapping all unimplemented CSRs to a benign, user-privilege read-write CSR
Instead, we now catch this RenameStage and steer it to a trap.
(2) MSTATUS.FS was initialized to 2'b00 (absent/off); should be 2'b01 (present and initial)
Previously, the request went out into the fabric, and we were relying
on the fabric returning an error response. Some fabrics don't do this
reliably, so this removes that reliance on the fabric.
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
