icache: Fix icache invalidation
This fixes two bugs in the flash invalidation of the icache. The first is that an instruction could get executed twice. The i-cache RAM is 2 instructions (64 bits) wide, so one read can supply results for 2 cycles. The fetch1 stage tells icache when the address is equal to the address of the previous cycle plus 4, and in cases where that is true, bit 2 of the address is 1, and the previous cycle was a cache hit, we just use the second word of the doubleword read from the cache RAM. However, the cache hit/miss logic also continues to operate, so in the case where the first word hits but the second word misses (because of an icache invalidation or a snoop occurring in the first cycle), we supply the instruction from the data previously read from the icache RAM but also stall fetch1 and start a cache reload sequence, and subsequently supply the second instruction again. This fixes the issue by inhibiting req_is_miss and stall_out when use_previous is true. The second bug is that if an icache invalidation occurs while reloading a line, we continue to reload the line, and make it valid when the reload finishes, even though some of the data may have been read before the invalidation occurred. This adds a new state STOP_RELOAD which we go to if an invalidation happens while we are in CLR_TAG or WAIT_ACK state. In STOP_RELOAD state we don't request any more reads from memory and wait for the reads we have previously requested to be acked, and then go to IDLE state. Data returned is still written to the icache RAM, but that doesn't matter because the line is invalid and is never made valid. Note that we don't have to worry about invalidations due to snooped writes while reloading a line, because the wishbone arbiter won't switch to another master once it has started sending our reload requests to memory. Thus a store to memory will either happen before any of our reads have got to memory, or after we have finished the reload (in which case we will no longer be in WAIT_ACK state). Signed-off-by: Paul Mackerras <paulus@ozlabs.org>pull/332/head
parent
83dea94793
commit
9b3b57710a
Loading…
Reference in New Issue