home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8437 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.3 KB  |  44 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!jjsmith
  3. From: jjsmith@nyx.cs.du.edu (Jonathan J. Smith)
  4. Subject: Re: Cached DRAM from Mitsubishi
  5. Message-ID: <1992Jul29.233244.27241@mnemosyne.cs.du.edu>
  6. X-Disclaimer: Nyx is a public access Unix system run by the University
  7.     of Denver for the Denver community.  The University has neither
  8.     control over nor responsibility for the opinions of users.
  9. Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
  10. Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
  11. References: <1992Jul29.214908.7876@trantor.harris-atd.com> <1992Jul29.224223.22285@beaver.cs.washington.edu>
  12. Date: Wed, 29 Jul 92 23:32:44 GMT
  13. Lines: 29
  14.  
  15. In article <1992Jul29.224223.22285@beaver.cs.washington.edu> noah@cs.washington.edu (Rick Noah Zucker) writes:
  16. >In article <1992Jul29.214908.7876@trantor.harris-atd.com> dwilliam@jabba.ess.harris.com (David Williams) writes:
  17. >>   I was flipping through the May issue of Electronic Design, and an
  18. >>ad from Mitsubishi caught my eye.  They have a DRAM chip now available
  19. >>with built-in cache.  This looks interesting - a 1M by 4 DRAM with a 
  20. >>built-in 4K by 4 SRAM cache.  Apparently, the chip has an internal bus
  21. >>that lets the SRAM cache do a line copy to/from the DRAM portion at
  22. >>64 bits.  (16 x 4bit internal bus)  Speed is claimed to be 10ns when a
  23. >>cache hit occurs, 70ns in case of a miss (actually, a miss causes a 
  24. >>280ns DRAM cycle, but the SRAM can start doing stuff again in 70ns while
  25. >>the DRAM is busy)
  26. >
  27. >    This is a little unclear, and if you have more detailed
  28. >information, please clarify my point.  You say that 70 ns after a cache
  29. >miss, the SRAM can start doing stuff, but the DRAM is busy for another
  30. >210 ns.  Does this mean that you will get your data in 70 ns, but the
  31. >DRAM is busy for another 210 ns because it has to write back the data you
  32. >just read out?  Or does it mean that you can initiate another request in
  33. >70 ns?  That is, you can make another request to the chip, which will be
  34. >satisfied if it is in the cache.
  35. >
  36. >                        Rick Noah Zucker
  37. >                        noah@cs.washington.edu
  38.  
  39.  
  40. From what I got out of the article, the dram reads an entire column of data from dram into the cache when a miss occurs.
  41. so that providing that the next read is within that column it can read in 70ns.
  42.  
  43. Jonathan
  44.