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
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
When controlled from a debugger (build with INCLUDE_GDB_CONTROL macro);
when stopped due a EBREAK instruction; on a 'resume' command ('continue' in GDB),
was getting stuck. This is now working.
At this point, all debugger functionality (almost: see below) is working:
halt, step, breakpoints, resume, read/write gpr/fpr/csr, read/write memory.
Still todo: "NDM reset" (non-debug module reset).
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.
This is not thoroughly tested, as we quickly throw an exception due to out-of-bounds memory and need some RVFI-DII control flow fixup to proceed further.
Otherwise, if the last instruction we tried to decode was the first half
of a 32-bit instruction, we will think the first 16-bit parcel from the
new PC is the second half of the previous instruction and take an
assertion failure because the PC does not match what was expected. This
fixes rv64uc-p-rvc, which broke after the previous commit as the
scheduling changes exposed this bug.
This conflict was introduced by 53aacff7c when compressed support was
added. Previously, doDecode could be scheduled in the same cycle as
doFetch3 (and only in that order), but the Reg reads added to doDecode
prevented this. Instead, use EHRs to allow a bypass path from doDecode
to doFetch3. This means we can issue every cycle again, rather than only
every other cycle.
This stopped unmapped addresses from faulting, instead giving back a
list of all Invalid entries, triggering the "Fetched insts not enough"
assertion in FetchStage's doDecode. Fixes rv64mi-p-access.
FMIN(sNaN, x), where x is not NaN, should behave like FMIN(qNaN, x) and
yield x rather than the canonical NaN. The only difference is that the
invalid operation flag should still be set despite not yielding NaN. The
same applies to FMAX.
Currently, our next address prediction cannot distinguish between a
taken compressed branch to PC+4 and an uncompressed instruction that
falls through. We can instead make the NAP machinery much more robust by
keying it on the 16b parcels, with uncompressed branches having their
taken prediction on the second 16b parcel. This also removes the need
for the address prediction requests to be chained.
Moreover, if we decode more than 2 instructions in one cycle due to
decompression, we throw away any subsequent instructions and treat it
like a branch miss, redirecting and thus restarting the pipeline from
the first discarded PC. We should therefore instead save them for
issuing on the next cycle and avoid the redirects. To ensure we don't
needlessly reduce our IPC, if we have a partial issue's width of
instructions saved, we should also support issuing instructions from the
next ICache response if valid, which should be the case in hot
correctly-predicted code paths, especially tight loops. As part of this
change, we also keep the pending straddle state in Fetch3 rather than
sending it to Decode only to have it be forwarded back.
Combined, these two approaches ensure the fetch unit can maintain an IPC
of 2 after it has had time to be correctly trained, regardless of the
distribution of compressed instructions.
Detail: an "instruction-fetch" response from mmioplatform to core
should be an "InstFetch". This was true for successful fabric reads,
but on error responses it was wrongly returned as a "DataAccess"
response. This was causing a deadlock.
