Newsgroups: sci.electronics
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: DRAM & Speeds needed...
Message-ID: <1990Jan30.163700.3520@utzoo.uucp>
Organization: U of Toronto Zoology
References: <26414@cup.portal.com>
Date: Tue, 30 Jan 90 16:37:00 GMT

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