We think that we were wedging on IFetch bus error.
It appears that we didn't make the last instruction fragment valid in the bus error case, and expect that this path was not previously exercised.
This change returns 0s (to hopefully make the error less subtle) in exactly the right number of fragments.
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).
It looks like PermitUnsealViolation and PermitSetCIDViolation were accidentally renumbered to fill in the gap left by the retired CCallAcessIDCViolation.
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.
instruction returned for an invalid fetch (that is, with a valid cause)
indicate a 2-fragment instruction but where a second fragment is not
available.
In the case where the prioritised round-robin source does not have a
request, this was always picking the earliest source that had one, which
means if some sources are making more requests than others (e.g. there
is lots of D$ churn but the I$ has a high hit rate) then, whilst the
cycles where srcRR[dst] prioritises a source that is making requests are
fair, the cycles where it prioritises a source that is not making
requests is not fair, since then the earlier sources will be
prioritised. Instead, make the fallback priority similarly dynamic so we
cycle through the order we look at the sources in.
