Made the proc start method non-blocking on mmio platform and wired in a new way
to set the tohost addr using a control and status request, and bumpped
WindCoreInterface accordingly
We think that we were wedging on IFetch bus error.
It appears that we didn't make the last instruction fragment valid in the bus error case, and expect that this path was not previously exercised.
This change returns 0s (to hopefully make the error less subtle) in exactly the right number of fragments.
This currently just loads in the data on cache miss, so won't help to reduce DRAM overhead, but will be forwards compatible and save on instructions in the revoker loop.
alignment of the original data.
Also eliminate the call to the reimplementation of the AMO functions.
(One call was already converted to use the common function, and I've now
converted the other.)
It's honestly unknown how much of this works, but it's more likely to
work than what was previously implemented, I think, given that the
previou implementation was based on some basic misconceptions concerning
data alignment.
Otherwise, the next MMIO access will see the 0 from the write response
instead of its response, and every subsequent access will see the
previous's response, further accumulating if more uncached AMOs are
performed.
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.
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
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.