🚀 go-pugleaf

In article <1993Jan6.235455.25425@Princeton.EDU>, awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
|> 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

The cache is accessed during the df/ds stages to read the tag, but the
write is not done at this time. The data to be stored is placed in a store
buffer and written into the cache at a later stage. The data cache has
seperately indexed data and tag arrays to allow this to work without 
adding additional stalls into the pipeline. Data in the store buffer is
written into the cache when there is spare bandwidth to the cache (when
there is a cycle when we are not accessing the cache for a load).

The store buffer obviously has logic to allow the data in it to be bypassed
to any other operations that need the data before it has been retired into
the cache.

Hope this helps,

Cheers,
Mike

-- 
   Michael S. Woodacre | Phone: (415) 390 4175
UUCP: {ames,pyramid,decwrl}!sgi!woodacre OR woodacre@sgi.com
USPS: MIPS Technologies Inc, M/S 10U-178,
      2011 N. Shoreline Blvd, Mountain View, CA 94039