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.
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.
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.
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.
Modified:
src_Core/RISCY_OOO/procs/lib/L2Tlb.bsv
In rule doPageWalk, if (!leafPte) ... else: added check for PPN alignment.
(In mega-/giga-page PTEs, lower bits of PPN must be zero for alignment)
Modified:
src_Core/RISCY_OOO/procs/RV64G_OOO/RenameStage.bsv
Bug fixes in 'getTrap' function:
- Trap if Fpu regs are accessed but mstatus_fs is "Off" (2'b00)
- Trap if r/w or privilege denies access to CSR in CSRRW/C/S instruction
src_Core/RISCY_OOO/procs/lib/ProcTypes.bsv
Bug fix: add support for 'u' bit in function 'getExtensionBits'
Regression status: RV64ADFIMSU_Toooba_verilator 204/229 PASS
(22 expected floating-point failures due to inaccurate modeling)
Modified
src_Core/RISCY_OOO/procs/lib/MMIOInst.bsv
Renamed 'BootRom' to 'IODevice'
Imported and instantiated SoC_Map
changed method getFetchTarget to use soc_map.is_IO_addr (phyPC)
to classify as IODevice
src_Core/RISCY_OOO/procs/RV64G_OOO/FetchStage.bsv
Changed 'BootRom' constant to 'IODevice' constant (just a renaming)
src_Testbench/SoC/SoC_Map.bsv
Changed boot rom classification from 'mem' to 'IO device'
Modified
src_Core/CPU/MMIO_AXI4_Adapter.bsv
Instead of aborting on axi4 mem read error, pass the error on to the core
src_Core/RISCY_OOO/procs/lib/MMIOAddrs.bsv
Added mainMemBoundAddr
src_Core/RISCY_OOO/procs/lib/MMIOCore.bsv
Update isMMIOAddr check to also check mainMemBoundAddr
src_Core/RISCY_OOO/procs/lib/MMIOInst.bsv
Update getFetchTarget to also check mainMemBoundAddr
(still TODO: allow other IO addrs other than bootRom)
Modified:
src_Core/CPU/CsrFile.bsv
Modified method 'trap' to use 'addr' for trap_val (MTVAL) instead of PC
for InstAccessFault and InstPageFault
src_Core/RISCY_OOO/procs/RV64G_OOO/FetchStage.bsv
Added 'tval' field to Fetch2Fetch3; set the value on TLB faults; send it out in 'FromFetchStage' struct
src_Core/RISCY_OOO/procs/RV64G_OOO/RenameStage.bsv
In rule doRenamingTrap, pass tval from FromFetchStage struct to ToReorderBuffer struct
src_Core/RISCY_OOO/procs/lib/ReorderBuffer.bsv
Add 'tval' Ehr to reorderbuffer slot, to accompany 'trap' Ehr.
In method write_enq, store tval from ToReorderBuffer arg into tval Ehr.
In method read_deq, send 'tval' Ehr value into 'ToReorderBuffer' output (goes to CommitStage)
src_Core/RISCY_OOO/procs/RV64G_OOO/CommitStage.bsv
Modified rule doCommitTrap_flush to take tval from 'ToReorderBuffer' input from ROB,
for InstAccessFault and InstPageFault
LICENSE
README.md
Clarified licensing of MIT code and Bluespec code
Tests/Run_regression.py
Emptied out 'exclude_list'
builds/RV64ADFIMSU_Toooba_verilator/Makefile
Added 'C' to Makefile
>----------------
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.
