Previously we were relying on the beat count registers being exactly the
right number of bits such that we'd overflow from 7 back to 0 after the
final flit. This change aligns the LLC adapter with the MMIO adapter,
which already does things in a safer way. We can also just look at rlast
for read respones rather than a full 3-bit comparison (the MMIO adapter
also makes this micro-optimisation).
If DRAM latency is too high and the cache is performing frequent writes,
it would be possible to overflow this counter, which means we don't rate
limit, the cache could erroneously believe it's safe to do I/O
accesses/cache refills/page table walks, and the cache would block due
to the guard on decr when it finally gets enough write responses back.
We should block the incr method to automatically stall the cache until
it receives a new write response.
The default was erroneously changed, causing P3 builds to have smaller
caches, so switch it back. The RVFI-DII builds override this with a TEST
configuration anyway now.
Also use RVFI_DII not RVFIDII in the directory names.
This makes everything match Piccolo/Flute rather than having Toooba be a
weird, inconsistent and plain wrong.
This one has the advantage of being able to be called with the same
flags as bsc, rather than needing to pass things through special
environment variables. As a result, revert all our changes to dealing
with BSC_COMPILATION_FLAGS (some of this diff therefore looks strangely
formatted, but it's to match upstream verbatim, and should be left that
way to minimise diffs and avoid conflicts).
testing.
To make this not fail, remove the reset server behaviour in SoC_Top
which appears to not be needed as it is only calling reset servers upon
actual reset when everything has been reset anyway.
I suppose these reset servers are meant for debug-unit-initiated reset
events.
alignment of the original data.
Also eliminate the call to the reimplementation of the AMO functions.
(One call was already converted to use the common function, and I've now
converted the other.)
It's honestly unknown how much of this works, but it's more likely to
work than what was previously implemented, I think, given that the
previou implementation was based on some basic misconceptions concerning
data alignment.
