Imperas found a bug with the Fence.I instruction.

If a fence.i directly followed a store miss, the d$ would release Stall during the cache line write.
Then transition to ReadHold.  This cause the d$ flush to go high while in ReadHold.  The solution is
to ensure the cache continues to assert Stall while in WriteLine state.

There was a second issue also.  The D$ flush asserted FlushD which flushed the I$ invalidate.
Finally the third issue was CacheEn from the FSM needs to be asserted on an InvalidateCache.
This commit is contained in:
Ross Thompson 2023-01-20 09:41:18 -06:00
parent ce7d92f2dc
commit 2cca457f14
2 changed files with 3 additions and 3 deletions

View File

@ -141,7 +141,7 @@ module cachefsm
assign CacheStall = (CurrState == STATE_READY & (FlushCache | AnyMiss)) |
(CurrState == STATE_FETCH) |
(CurrState == STATE_WRITEBACK) |
(CurrState == STATE_WRITE_LINE & ~(StoreAMO)) | // this cycle writes the sram, must keep stalling so the next cycle can read the next hit/miss unless its a write.
(CurrState == STATE_WRITE_LINE) | // this cycle writes the sram, must keep stalling so the next cycle can read the next hit/miss unless its a write.
(CurrState == STATE_FLUSH) |
(CurrState == STATE_FLUSH_WRITEBACK);
// write enables internal to cache
@ -181,6 +181,6 @@ module cachefsm
resetDelay;
assign SelFetchBuffer = CurrState == STATE_WRITE_LINE | CurrState == STATE_READ_HOLD;
assign CacheEn = (~Stall | FlushCache | AnyMiss) | (CurrState != STATE_READY) | reset;
assign CacheEn = (~Stall | FlushCache | AnyMiss) | (CurrState != STATE_READY) | reset | InvalidateCache;
endmodule // cachefsm

View File

@ -152,7 +152,7 @@ module cacheway #(parameter NUMLINES=512, parameter LINELEN = 256, TAGLEN = 26,
if (reset) ValidBits <= #1 '0;
if(CacheEn) begin
ValidWay <= #1 ValidBits[CAdr];
if(InvalidateCache & ~FlushStage) ValidBits <= #1 '0;
if(InvalidateCache) ValidBits <= #1 '0;
else if (SetValidEN | (ClearValidWay & ~FlushStage)) ValidBits[CAdr] <= #1 SetValidWay;
end
end