Despite the name, we can end up having a pending_straddle at an "even"
PC (and thus an "odd" pc_start). In this case, we would erroneously
treat it as if pc_start were "even", effectively shifting all the
instruction parcels along by one and duplicating the first one, since
the first element of the parcels vector will be a copy of the straddle's
parcel itself. Instead, we should just ignore pending_straddle when
determining where to start in the parcels vector, as the two are
completely independent, and no longer hard-code that the straddle is
merged with element 0.
This can happen if we predict that the first half of an uncompressed
instruction is a taken branch. We will have the instruction bytes
available, but not the prediction information, so still have to do a
normal Fetch3 redirect in the same manner as an unaligned uncompressed
instruction. We could perhaps special-case with a fast-path (or query
the predictor directly in Fetch3), but it should hit in the TLB and L1
cache, and is probably not common enough to warrant the complexity.
The FreeRTOS-based netboot loader trips up on this as it overwrites
itself with the payload, and thus all the branch prediction still has
many taken branch entries, most of which will not be correct.
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.
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 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.
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
>----------------
