[sci.electronics] DRAM & Speeds needed...

Ordania-DM@cup.portal.com (Charles K Hughes) (01/30/90)

  I am having a bit of trouble with processor speeds versus DRAM speeds.
I am working on an 8MHz 6502/65816 design and I need to know what speed 
of DRAM I need.  The spec sheets for the 6502 list a 60ns access time,
but I am having trouble believing this when there are 33MHz '386 machines
using 80ns drams.  Could somebody explain how this works and what speed 
I would need to use?
  That was the first part - now for the second.  Along the same lines I need
to perform a great deal of address decoding for addresses $000000-$00FFFF
and I cannot figure out how to do them without introducing wait states.  Does
anyone know of any general purpose memory mappers/decoders that work at high
speeds? (8/16Mhz - real clock speed - 1 read/write per cycle)

Thanks
 Charles_K_Hughes
@cup.portal.com

henry@utzoo.uucp (Henry Spencer) (01/31/90)

In article <26414@cup.portal.com> Ordania-DM@cup.portal.com (Charles K Hughes) writes:
>I am working on an 8MHz 6502/65816 design and I need to know what speed 
>of DRAM I need.  The spec sheets for the 6502 list a 60ns access time,
>but I am having trouble believing this when there are 33MHz '386 machines
>using 80ns drams.  Could somebody explain how this works...

You've discovered Excedrin Headache Number 3.14159 of fast processor design:
figuring out how to make the memory fast enough to keep up.  386 and 6502
clock speeds are not directly comparable, so that analogy doesn't hold up.
An 8MHz 6502 has a 125ns cycle, during which it has to do an entire memory
access plus overhead (the 386 spreads this over multiple cycles).  Taking
half the cycle for overhead is a little much, but not grossly implausible
for a basically low-speed part pushed to higher speeds.

There is no simple way to figure out how fast a memory you need for a
given processor speed.  You have to sketch out your memory design and
then go through the access path, adding up delays introduced by processor,
decoding, buffers, etc.  Whatever time you have left in the cycle is
your memory access time.  Processors often set upper bounds on this by
having only so much time available between the time all the address and
control lines are stable and the time when the data is required; that's
probably what your "60ns" figure is.  Cleverness can sometimes beat this
a little bit, by getting things started early, but that's very design-
specific.

>  That was the first part - now for the second.  Along the same lines I need
>to perform a great deal of address decoding for addresses $000000-$00FFFF
>and I cannot figure out how to do them without introducing wait states...
>... (8/16Mhz - real clock speed - 1 read/write per cycle)

With only 60ns to work with, I can understand having some problems with this!
You might want to look at some of the specialized PALs from folks like TI,
which are aimed at precisely this problem.  (Don't have part numbers handy,
I'm afraid.)  Basically, though, what you are trying to do is difficult,
and you're going to have to resign yourself to warping your design to
minimize bottlenecks (a design which does "a great deal" of decoding simply
isn't suited to high-speed operation) and to paying through the nose for
seriously fast memory and seriously fast support parts.
-- 
1972: Saturn V #15 flight-ready|     Henry Spencer at U of Toronto Zoology
1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

davidc@vlsisj.VLSI.COM (David Chapman) (02/03/90)

In article <1990Jan30.163700.3520@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
|In article <26414@cup.portal.com> Ordania-DM@cup.portal.com (Charles K Hughes) writes:
|>I am working on an 8MHz 6502/65816 design and I need to know what speed 
|>of DRAM I need.  The spec sheets for the 6502 list a 60ns access time,
|>but I am having trouble believing this when there are 33MHz '386 machines
|>using 80ns drams.  Could somebody explain how this works...
|
|You've discovered Excedrin Headache Number 3.14159 of fast processor design:
|figuring out how to make the memory fast enough to keep up.  386 and 6502
|clock speeds are not directly comparable, so that analogy doesn't hold up.
|An 8MHz 6502 has a 125ns cycle, during which it has to do an entire memory
|access plus overhead (the 386 spreads this over multiple cycles).  Taking
|half the cycle for overhead is a little much, but not grossly implausible
|for a basically low-speed part pushed to higher speeds.

Also, if you're paying lotsa bucks for a 33 MHz 386 system, they'll often
have cache memory in them.  95% of your accesses go into a 25 or 30 ns
64K SRAM.  This might not be easy to add for a 6502/65816, however.  It 
also costs money, just like 60 ns DRAMs.
-- 
		David Chapman

{known world}!decwrl!vlsisj!fndry!davidc
vlsisj!fndry!davidc@decwrl.dec.com