From: jon@alpha.ee.ufl.edu (Jon Mellott)
Newsgroups: comp.arch
Subject: Re: Cached DRAM from Mitsubishi
Date: 30 Jul 92 16:27:50 GMT
Organization: EE Dept at UF

In article <1992Jul30.142857.10787@ntuix.ntu.ac.sg>, eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
|> In article <1992Jul30.003907.10654@eng.ufl.edu> jon@alpha.ee.ufl.edu (Jon Mellott) writes:
|> 
|> : 
|> : The vital statistics (for the -10 suffix devices) are:
|> : 1) Cache Hit Access/Cycle = 10ns/10ns
|> 
|> At this speed, we start questioning the need for internal caches in Alpha and
|> P5. Even with 128 pins for Alpha, it cannot beat the 16 data width for 
|> each output bit of the DRAM cache. This is just the beginning.

I don't think so. For starters, the external interconnect (read external buses) 
cannot compete in speed with the internal buses. For example, the last time 
I checked, the 200 MHz alpha has a 50 MHz external bus. Thus, the external 
bus cannot go anywhere near as fast as the internal clock rate of the processor.
Furthermore, for SMP machines, internal processor (and processor local) caches 
reduce traffic per processor to main memory, thus leaving more available 
bandwidth. 

|> 	The question is, what sort of technology is used to bring static and
|> DRAM technology together? Will it ever be cheaply mass produced?

It was probably a standard DRAM process. The DRAM certainly represents most 
of the area of such a device. Plus, the DRAM process has the extra goodies 
it takes to make small capacitors, which the SRAM process would not have. 
Cheaply mass produced? Well, it will probably always be more expensive than 
standard DRAM since this device would chew up more silicon and have lower 
yields than a standard 4 Mbit DRAM. Ultimately, the pricing will depend upon 
the volume demand and the available supply. This is very dependent upon 
the device getting some major design wins, which, is probably linked to 
whether the device can be second sourced. Many manufacturers will not touch 
a device which does not have a second source: exceptions may be made for a 
device such as an i486 (which defines a market), but the memory is not such 
a device. 

|> 	Instead of 4 bit wide data per chip, when will they put 16-bit wide
|> packages on the standard(JEDEC?) 40-pin packages.
|> 
It's not very likely that you will see DRAM in packages larger than 4 bits 
wide for quite some time (maybe the 64 Mbit generation). The reason is that 
DRAM users typically build large banks of memory and it is advantageous to 
have long, skinny organizations rather than short, fat organizations since 
this saves on costly bank decoding logic. 

On the other hand, you can find EPROMs (and, I think EEPROMS & Flash) in x16 
organizations. This reflects their target audience: systems where the memory 
is used for bootstrap loaders and the like, and there is motivation to reduce 
the device count. 

|> I wish that someone more knowledgeable could contribute.
|> 
Gee, call your Mitsubishi rep and ask him their strategic marketing plans. 
I'm sure that he'll tell you what you want to hear if you commit to 
a couple of hundred thousand units per month.

|> : 2) Cache Miss Access/Cycle = 70ns/280ns *
|> 
|> After 16 write cycles of  10nS each, it must be followed by a 70nS cycle. 
|> However if there is a backward jump to the previous bank, the cycle time
|> would be 280nS. I am cloudy here.
                   ^^^^^^^^^^^^^^^^ -- Yep.
You're thinking more along the lines of a page mode or static column device.
This device is *cached* with multiple lines of cache (page mode/static column
devices effectively have a cache of *one* line).

|> 	I thought that caches are good only for random access. Here is an
|> example of cache optimised for sequential access. I agree that sequential
|> access is the most common for microprocessor.

It would seem that most caches (especially those on microprocessors) use 
burst filling to fill a line of the cache and thus, by your way of thinking, 
are optimized for sequential access. Although this cache is *probably* direct 
mapped, it is probably very helpful for random access: otherwise, why bother?
Of course, we could always throw some vector operations at the memory bank 
and make the cache on this device no more useful than the static column mode 
on SCRAMs.

|> : 3) Direct Array Access/Cycle = 70ns/140ns
|> This mode is only necessary for completely random accesses.
|> 

This is probably motivated by a couple of things. One, refresh still has to 
happen (and it cannot be cached). Two, this gives better observability of the 
DRAM array, thus allowing POST to perform good fault detection. Another good 
use for this would be for low speed DMA transfers by I/O channels. 

|> The above are just my guesses. Anyone can comment on that?
|> 
Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
Newsgroups: comp.arch