It's currently unknown to me what the function of tval in the reorder
buffer was, which is a bit scary.
It seemed to have some additional calculation to do with instruction
alignment, but verification with compressed instructions still seems to
work.
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.
Previously we were relying on the beat count registers being exactly the
right number of bits such that we'd overflow from 7 back to 0 after the
final flit. This change aligns the LLC adapter with the MMIO adapter,
which already does things in a safer way. We can also just look at rlast
for read respones rather than a full 3-bit comparison (the MMIO adapter
also makes this micro-optimisation).
If DRAM latency is too high and the cache is performing frequent writes,
it would be possible to overflow this counter, which means we don't rate
limit, the cache could erroneously believe it's safe to do I/O
accesses/cache refills/page table walks, and the cache would block due
to the guard on decr when it finally gets enough write responses back.
We should block the incr method to automatically stall the cache until
it receives a new write response.
The default was erroneously changed, causing P3 builds to have smaller
caches, so switch it back. The RVFI-DII builds override this with a TEST
configuration anyway now.
Also use RVFI_DII not RVFIDII in the directory names.
This makes everything match Piccolo/Flute rather than having Toooba be a
weird, inconsistent and plain wrong.
This one has the advantage of being able to be called with the same
flags as bsc, rather than needing to pass things through special
environment variables. As a result, revert all our changes to dealing
with BSC_COMPILATION_FLAGS (some of this diff therefore looks strangely
formatted, but it's to match upstream verbatim, and should be left that
way to minimise diffs and avoid conflicts).
