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.
We needlessly casted to CapPipe then FpuMulDivExePipeline had to
internally get the address and construct null-derived capabilities. Push
all this out to the Core so that it just deals with Data again. This is
unlikely to affect area as any sane optimiser would have optimised all
this away, but this is cleaner code, with the benefit that the FPU no
longer cares if the physical register file is unified or split between
GPCRs and FPRs.
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.
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.
PLIC: updated to latest version from Piccolo/Flute.
MMIO_AXI4_Adapter: added workaround for Xilinx IP problem on 64-bit
AXI4 fabrics. Writes that specify 8-byte size, but only write in
upper or lower word using strobes, are converted into 4-byte size.
Core.bsv: added a notification to the Debug Module re. CPU halt.
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.
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.
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.
>----------------
Status and outlook:
For RV64GC, out of 229 standard ISA tests, 202 PASS, 27 FAIL.
Below is a list of current failures, current diagnoses, and outlook.
'C' instructions:
rv64uc-v-rvc
Diagnosis: error in saved regs during instruction page fault
when a 32-bit instruction straddles a page boundary and
the second 16-bits encounters a page fault.
Note: the corresponding rv64uc-p-rvc passes, containing
the same set of tests except for the virtual-memory
aspect, so we expect this test to pass once this issue is
fixed.
Outlook: Target date for fix: 2019-Apr-09 (today)
System instructions:
rv64mi-p-access
rv64mi-p-csr
rv64si-p-dirty
rv64mi-p-illegal
Diagnosis: we do not have accurate diagnoses yet, although
some symptoms look similar to what we saw with earlier
processors (these test various corner-cases of system
instructions).
Outlook: Target date for fix: 2019-Apr-15
'F' and 'D' instructions
rv64uf-p-fadd rv64uf-v-fadd
rv64uf-p-fcmp rv64uf-v-fcmp
rv64uf-p-fdiv rv64uf-v-fdiv
rv64uf-p-fmin rv64uf-v-fmin
rv64ud-p-fadd rv64ud-v-fadd
rv64ud-p-fcmp rv64ud-v-fcmp
rv64ud-p-fdiv rv64ud-v-fdiv
rv64ud-p-fmadd rv64ud-v-fmadd
rv64ud-p-fmin rv64ud-v-fmin
rv64ud-p-ldst rv64ud-v-ldst
rv64ud-p-move rv64ud-v-move
Diagnosis: These seem to be simulation-only errors. Simulation
uses some quick-and-dirty floating-point "model" modules
written by the MIT authors, which are not accurate. All
the errors seem to be regarding incomplete treatment of
NaNs in the models. These errors should not happen in
FPGA since those use Xilinx IP modules instead. MIT has
been booting Linux with the Xilinx IP modules, lending
more confidence in the FPGA version.
The actual number of root-cause failures is likely to be
smaller than the list. For example, the 'fadd' test has
four variants: {uf/ud} x {-p-/-v-}; they all likely need a
comon fix.
Outlook: Target date: 2019-Apr-30
[Lower priority, since FPGA versions should be ok even now.]
>----------------
Detailed comments on file changes
New files:
Doc/micro2018.pdf
MIT's paper on RISCY-OOO at IEEE Micro
src_Core/CPU/CPU_Decode_C.bsv
Function to expand 'C' instrs to 32-bit counterparts, taken from Piccolo/Flute
Modified files:
src_Core/CPU/Core.bsv
Added rob_getOrig_Inst method
src_Core/RISCY_OOO/procs/RV64G_OOO/AluExePipeline.bsv
Added 'orig_inst' stuff, $displays
src_Core/RISCY_OOO/procs/RV64G_OOO/CommitStage.bsv
Mostly verbosity stuff, including printing out brief instruction trace similar to Piccolo/Flute.
src_Core/RISCY_OOO/procs/RV64G_OOO/FetchStage.bsv
Major changes for 'C', including call to Decode_C function from Piccolo/Flute
Pass orig_inst to downpipe.
src_Core/RISCY_OOO/procs/RV64G_OOO/RenameStage.bsv
Added 'orig_inst', input from FetchStage and passed on to ROB
Tweaked PC+4 check to accommodate 'C' instructions.
src_Core/RISCY_OOO/procs/lib/BrPred.bsv
Fixed 'decodeBrPred' to accommodate 'C' instructions
src_Core/RISCY_OOO/procs/lib/Exec.bsv
Fixed 'brAddrCalc', 'getControlFlow', 'basicExec' to acommodate 'C' instructions
src_Core/RISCY_OOO/procs/lib/MemLoader.bsv
Switched off 'verbose' by default
src_Core/RISCY_OOO/procs/lib/ProcTypes.bsv
Added 'C' to MISA, 'getExtensionBits'
src_Core/RISCY_OOO/procs/lib/ReorderBuffer.bsv
Added 'orig_inst' register to basic cell, and methods to set/access.
src_Core/RISCY_OOO/procs/lib/Types.bsv
Added typedefs for 'C' instructions
>----------------
New method 'debug_external_interrupt_req' to support emulation of a
debug module starts at P3_Core interface and is plumbed all the way in
to the CSR register MIP as interrupt [14]. The corresponding MIE[14]
is always 1, so it is never masked. Still todo: should not be masked
by MSTATUS interrupt-enables either. Also expanded
interrupt-detection logic, mcause etc. to extend up to interrupt 14.
Builds in standalone mode, runs ISA tests.
Builds in src_SSITH_P3, generating RTL.
