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.
This should not be a primary degredation of performance since the
redirection gets on seperately from this update which will only affect
future predictions.
improvements that can be upstreamed.
Basically, only use addresses in these predictors rather than
capabilities, and just pass an address in from the FetchStage.
All of St, Amo, Lr and Sc use the normal 3-bit encoding for the width;
rather than add Lr and Sc to the list, switch it just to exclude Ld as
the special case that's handled by the other half of the expression.
Previously LR.C and SC.C were decoded as LR.BU and SC.BU.
These checks were broken in several ways:
1) a missing 'else' inverted the priority of PermitStoreViolation vs. PermitStore[Local]Cap exceptions
2) another missing 'else' inverted the priority of PermitStoreCap and PermitStoreLocalCap exceptions
3) No store checks were performed when mem_func == Amo because of the preceding if clause for loads
I decided to flatten the nested if statements by pulling out the conditions into boolean local variables. Hopefully this makes it clearer (as well as fixing the bugs).
indices due to the head-1 element happening to match new requests.
This leads to "remove" when empty, leading to being "almostFull" when
there are no outstanding users that will remove anything.
