home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / arch / 8471 < prev    next >
Encoding:
Internet Message Format  |  1992-07-30  |  5.1 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!eng.ufl.edu!alpha.ee.ufl.edu!jon
  2. From: jon@alpha.ee.ufl.edu (Jon Mellott)
  3. Newsgroups: comp.arch
  4. Subject: Re: Cached DRAM from Mitsubishi
  5. Message-ID: <1992Jul30.162750.14677@eng.ufl.edu>
  6. Date: 30 Jul 92 16:27:50 GMT
  7. References: <1992Jul30.003907.10654@eng.ufl.edu> <1992Jul30.142857.10787@ntuix.ntu.ac.sg>
  8. Sender: news@eng.ufl.edu (Usenet Diskhog System)
  9. Organization: EE Dept at UF
  10. Lines: 92
  11.  
  12. In article <1992Jul30.142857.10787@ntuix.ntu.ac.sg>, eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
  13. |> In article <1992Jul30.003907.10654@eng.ufl.edu> jon@alpha.ee.ufl.edu (Jon Mellott) writes:
  14. |> 
  15. |> : 
  16. |> : The vital statistics (for the -10 suffix devices) are:
  17. |> : 1) Cache Hit Access/Cycle = 10ns/10ns
  18. |> 
  19. |> At this speed, we start questioning the need for internal caches in Alpha and
  20. |> P5. Even with 128 pins for Alpha, it cannot beat the 16 data width for 
  21. |> each output bit of the DRAM cache. This is just the beginning.
  22.  
  23. I don't think so. For starters, the external interconnect (read external buses) 
  24. cannot compete in speed with the internal buses. For example, the last time 
  25. I checked, the 200 MHz alpha has a 50 MHz external bus. Thus, the external 
  26. bus cannot go anywhere near as fast as the internal clock rate of the processor.
  27. Furthermore, for SMP machines, internal processor (and processor local) caches 
  28. reduce traffic per processor to main memory, thus leaving more available 
  29. bandwidth. 
  30.  
  31. |>     The question is, what sort of technology is used to bring static and
  32. |> DRAM technology together? Will it ever be cheaply mass produced?
  33.  
  34. It was probably a standard DRAM process. The DRAM certainly represents most 
  35. of the area of such a device. Plus, the DRAM process has the extra goodies 
  36. it takes to make small capacitors, which the SRAM process would not have. 
  37. Cheaply mass produced? Well, it will probably always be more expensive than 
  38. standard DRAM since this device would chew up more silicon and have lower 
  39. yields than a standard 4 Mbit DRAM. Ultimately, the pricing will depend upon 
  40. the volume demand and the available supply. This is very dependent upon 
  41. the device getting some major design wins, which, is probably linked to 
  42. whether the device can be second sourced. Many manufacturers will not touch 
  43. a device which does not have a second source: exceptions may be made for a 
  44. device such as an i486 (which defines a market), but the memory is not such 
  45. a device. 
  46.  
  47. |>     Instead of 4 bit wide data per chip, when will they put 16-bit wide
  48. |> packages on the standard(JEDEC?) 40-pin packages.
  49. |> 
  50. It's not very likely that you will see DRAM in packages larger than 4 bits 
  51. wide for quite some time (maybe the 64 Mbit generation). The reason is that 
  52. DRAM users typically build large banks of memory and it is advantageous to 
  53. have long, skinny organizations rather than short, fat organizations since 
  54. this saves on costly bank decoding logic. 
  55.  
  56. On the other hand, you can find EPROMs (and, I think EEPROMS & Flash) in x16 
  57. organizations. This reflects their target audience: systems where the memory 
  58. is used for bootstrap loaders and the like, and there is motivation to reduce 
  59. the device count. 
  60.  
  61. |> I wish that someone more knowledgeable could contribute.
  62. |> 
  63. Gee, call your Mitsubishi rep and ask him their strategic marketing plans. 
  64. I'm sure that he'll tell you what you want to hear if you commit to 
  65. a couple of hundred thousand units per month.
  66.  
  67. |> : 2) Cache Miss Access/Cycle = 70ns/280ns *
  68. |> 
  69. |> After 16 write cycles of  10nS each, it must be followed by a 70nS cycle. 
  70. |> However if there is a backward jump to the previous bank, the cycle time
  71. |> would be 280nS. I am cloudy here.
  72.                    ^^^^^^^^^^^^^^^^ -- Yep.
  73. You're thinking more along the lines of a page mode or static column device.
  74. This device is *cached* with multiple lines of cache (page mode/static column
  75. devices effectively have a cache of *one* line).
  76.  
  77. |>     I thought that caches are good only for random access. Here is an
  78. |> example of cache optimised for sequential access. I agree that sequential
  79. |> access is the most common for microprocessor.
  80.  
  81. It would seem that most caches (especially those on microprocessors) use 
  82. burst filling to fill a line of the cache and thus, by your way of thinking, 
  83. are optimized for sequential access. Although this cache is *probably* direct 
  84. mapped, it is probably very helpful for random access: otherwise, why bother?
  85. Of course, we could always throw some vector operations at the memory bank 
  86. and make the cache on this device no more useful than the static column mode 
  87. on SCRAMs.
  88.  
  89. |> : 3) Direct Array Access/Cycle = 70ns/140ns
  90. |> This mode is only necessary for completely random accesses.
  91. |> 
  92.  
  93. This is probably motivated by a couple of things. One, refresh still has to 
  94. happen (and it cannot be cached). Two, this gives better observability of the 
  95. DRAM array, thus allowing POST to perform good fault detection. Another good 
  96. use for this would be for low speed DMA transfers by I/O channels. 
  97.  
  98. |> The above are just my guesses. Anyone can comment on that?
  99. |> 
  100. Jon Mellott
  101. High Speed Digital Architecture Laboratory
  102. University of Florida
  103. (jon@alpha.ee.ufl.edu)
  104.