🚀 go-pugleaf

I am unclear on the timing involved when write misses occur on a write-back
cache (like in the R4000).  Perhaps someone can clarify.

When a write is attempted - a virtual index is used to select a cache line
and a virtual offset selects bytes within that line.  This happens during
the DF stage in the R4000.  The memory can then be accessed during the DS
stage.  I assume that the tag is read at this time.  If a write is allowed
to occur at this time - it may destroy data in the cache.

The tag is checked at the next stage (TC).  If the tags match - all is OK -
but if the tags do not match, then I have written over the previous data in
the cache.  If I delay stores until after the tag check - then the memory is
busy with another instruction in the pipeline.



I can conceive of several possible solutions:

1)  Always save a copy of the overwritten line (for writeback).

2)  Delay the write - then simultaneously read and write the cache.
    (write from instruction in TC, read from instruction in MS)

3)  Delay the write - then stall the pipeline on a hit or miss if the next 
    instruction is a load.

The first two require a heavy-duty dual-ported cache.  The third requires
stalls that I cannot find documented.

What method is really used to solve this problem in the R4000 and similar
write-back caches?


-- 
--------------------------------------
Andrew Wolfe
Assistant Professor
Department of Electrical Engineering
Princeton University