(Previously we ran into the limit of ports on the regFiles holding state
in the BTB. This uses a vector of regFiles with a vector of interfaces,
which is logically the same but might produce multiple copies of state.)
Evidence of "working" is passing TestRIG to a cursory depth including
compressed instructions and running CoreMark in simulation.
This one appears to be 2.5% slower than the existing design in CoreMark,
so some optimisation should be done. We expect it to be a bit faster
than the original due to more flexibility in decoding instructions from
different fetch units together.
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.
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
