home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.arch
- Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!princeton!moo!awolfe
- From: awolfe@moo.Princeton.EDU (Andrew Wolfe)
- Subject: How does an R4000-style cache work?
- Message-ID: <1993Jan6.235455.25425@Princeton.EDU>
- Originator: news@nimaster
- Keywords: Write-back Cache
- Sender: news@Princeton.EDU (USENET News System)
- Nntp-Posting-Host: moo.princeton.edu
- Organization: Princeton Univ.
- Date: Wed, 6 Jan 1993 23:54:55 GMT
- Lines: 39
-
- 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
-