We determined that this case is not hit even for i$, so this
case is also excluded separately for i$. It could be a better
idea to remove the ~FlushStage check completely (if we're sure).
My reasoning for this one is written as a comment in the exclusion
script: since a pipeline stall is asserted by the cache in the fetch
stage (which happens before going into the WRITE_LINE state and
asserting SetValidWay), there seems to be no way to trigger
a FlushStage (FlushW for D$) while the stallM is active.
FlushWay is always 1 for one way, but by default it is only 1 for
way 0.
The logic that advances FlushWay to ways 1, 2, and 3 only does so
on a subset of conditions that SelFlush is high (in cachefsm), so
this is unreachable for cachways 1-3.
The InvalidateCache signal in the D$ is for I$ only, which
causes some coverage issues that need exclusion.
Another manual exclusion is due to the fact that D$ writeback, flush,
write_line, or flush_writeback states can't be cancelled by a flush,
so those transistions are excluded.
There is some other small stuff to review (logic simplification,
or an exclusion pragma if removing the redundent logic would
make it harder to understand the code, as is the case in the
FlushAdrCntEn assign statement, in my opinion).
The genvar stuff was switched to readable names to make it easier
to understand for the first time. In the LRUUpdate logic for loop,
a special case was added for simpler logic in the case of the root
node, to hit coverage.
For coverage.
LRUWriteEn is gated by FlushStage in cache.sv,
so removing the signal completely avoids future confusion.
Update cache.sv to reflect cacheLRU edit.
Spent a long time trying to find a way to see if this condition was
possible, only to become relativly convinced that it isn't.
Basically, since RO cache writes only happen after a long period of
stall for the bus access, there's no way a flushD can be active
at the same time as a RO cache write. TrapM causes a FlushD, but
interrupts are gated by the "commited" logic and the exception
pipeline stalls.
I feel like its worth keeping the logic to be safe
so I've chosen to exclude it rather than explicitely remove it.
The cachefsm hardwired ClearValid logic to zero.
This signal might've been added to potentially add extra functionality
later. Unless that functionality is added, however, it negatively
impacts coverage. If the goal is to maximize coverage, this signal
should be removed and only added when it becomes necessary.
I found the problem. We use a Committed(F/M) signal to indicate the IFU or LSU has an ongoing cache or bus transaction and should not be interrupted. At the time of the mret, the IFU is fetching uncacheable invalid instructions asserting CommittedF. As the IFU finishes the request it unstalls the pipeline but continues to assert CommittedF. (This is not necessary for the IFU). In the same cycle the LSU d cache misses. Because CommittedF is blocking the interrupt the d cache submits a cache line fetch to the EBU.
I am thinking out loud here. At it's core the Committed(F/M) ensure memory operations are atomic and caches don't get into inconsistent states. Once the memory operation is completed the LSU/IFU removes the stall but continues to hold Committed(F/M) because the memory operation has completed and it would be wrong to allow an interrupt to occur with a completed load/store. However this is not true of the IFU. If we lower CommittedF once the operation is complete then this problem is solved. The interrupt won't be masked and the LSU will flush the d cache miss.
This requires a minor change in the cachebusfsm and cachefsm. I will report back after I've confirmed this works.
