Just update the head in Decode, and write data from Execute.
A loop calling from the same place will at least find the correct
address.
Also, the bad fixup interaction is solved.
A push updates the head pointer from Execute, but the instructions
between Decode and execute will have an out-of-date head pointer.
If a branch in that window mispredicts, it will get the head pointer
out of sync by resetting it to ignore the push.
By delaying by one branch, we seem to eliminate over 60% of the misses,
and reduce the cycle overhead from 0.5% to 0.2% in CoreMark, and still
well ahead of the baseline with no fixup.
That is, don't push in Decode, push from the training structure coming
from Execute, which is delayed until the instruction that issued it is
non-speculative.
Commit stage redirections are post-prediction and should need to somehow
be treated specially in the SpecFifo for epochs in the fetch stage.
They are post-commit, so should be unkillable somehow. I guess
SpecFifos are not meant to hold post-commit state currently.
defined).
This is done by adding a vector of padder lookup interfaces to the load
store queue.
This should help with targeted memory translation debugging, and also
with compatability with the current Sail RVFI implemenation which is
probably incorrect with respect to the RVFI spec which calls for virtual
addresses in the maddr field.
Add a "nextPc" interface so that lookup can begin in the previous cycle.
Remove the "pc" operands in the vector of lookup interfaces,
but rather derive the PC from lookup from the first PC being looked up
in that cycle. That is, by adding 4*(interface number) to the beginning
lookup PC. As this might not actually be the PC of the instruction,
pass the index you used with the training info so that you are certain
to train with the same index you looked up.
This has less than 1% overhead in CoreMark.
This is a general improvement for reasonable timing which should be upstreamed.
the vector of instructions outside of the decode loop to improve timing.
Specifically, the branch direction prediction is lifted out and depends
only on whether there is agreement between direction prediction and a
branch being predicted by fetch, not on the actual predicted next PC.
This appears to keep the global history clean enough to
perform on-par with the old design in CoreMark.
This is a general timing improvement and should be upstreamed.
This should not be a primary degredation of performance since the
redirection gets on seperately from this update which will only affect
future predictions.
