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.
BSC does not play nicely with enums whose labels do not start at 0 and
increase linearly. Instead, in such cases, it generates a whole bunch of
conditions to "legalise" any read values, which causes an explosion of
logic in places like the ROB. Thus, use this ugly (but still typed)
alternative that, other than naming conventions enforced by BSC, looks
almost the same as an enum.
This gives traceBundle its own set of ports. Also fix the nonsensical
calculations for those Ehr ports; the number of FPUs should not be
calculated as ALUs/2!
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.
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.
