home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!eng.ufl.edu!alpha.ee.ufl.edu!jon
- From: jon@alpha.ee.ufl.edu (Jon Mellott)
- Newsgroups: comp.arch
- Subject: Re: Cached DRAM from Mitsubishi
- Message-ID: <1992Jul30.162750.14677@eng.ufl.edu>
- Date: 30 Jul 92 16:27:50 GMT
- References: <1992Jul30.003907.10654@eng.ufl.edu> <1992Jul30.142857.10787@ntuix.ntu.ac.sg>
- Sender: news@eng.ufl.edu (Usenet Diskhog System)
- Organization: EE Dept at UF
- Lines: 92
-
- 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)
-