Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!orca!ka7axd.wv.tek.com
From: mhorne@ka7axd.wv.tek.com (Mike Horne)
Newsgroups: comp.dsp
Subject: Re: Building a DSP board, Part Four: Hooking up RAM & ROM
Message-ID: <4759@orca.WV.TEK.COM>
Date: 29 Sep 89 16:43:49 GMT
References: <1989Sep29.051916.7920@ivucsb.sba.ca.us>
Sender: nobody@orca.WV.TEK.COM
Reply-To: mhorne@ka7axd.wv.tek.com
Organization: Tektronix, Inc., Wilsonville, OR
Lines: 56

In the ongoing series from Todd:
>Building a DSP board, Part Four: Hooking up RAM & ROM
>-----------------------------------------------------
>
>I chose to use static RAMs since the 56000 doesn't have a
>built in RAM refresh.  The only problem with this choice is
>that they are *expensive*, especially the fast ones.  Thankfully,
>Integrated Device Technologies came to my aid and gave me four
>64k x 16bit 70ns SRAMS.  Unfortunately, these are not quite
>fast enough to go with no wait states (<60 ns would do it).
>

Just as a suggestion, I'd recommend the standard 4K/16K/64K X 4 static RAM
series available from many vendors (Moto being one of them).  They have the
advantage of being somewhat pin compatible, that is, you can arrange a single
24-pin skinny (300 mil) DIP to accept any of these parts with a few jumpers.
If you limit yourself to just 16K/64K parts, it reduces to just a single jumper.
The nicest thing about them (if you use DIPs) is that they take up very little
room.  To achieve the same amount of memory using N X 8 parts, which are in
600 mil wide DIPs, you end up taking twice as much board space for the SRAM
(e.g 64K X 24 takes six 300 mil parts when using the 64K X 4 parts, but it
takes six 600 mil parts when using the 32K X 8 parts, about double the board
space).

Also, the speeds available are plenty fast for the 56K, and with care can be
used with the newer, faster DSPs.  I believe they are available down to 25 nS,
but they may be available in faster speeds these days (20? 15?).  I don't
feel one should skimp when it comes to external RAM since wait states *really*
affect your system performance (hence Moto's inclusing of fast SRAM on-board).
If you are extremely cost conscious, you may not be able to afford it, but the
prices for the above parts are fairly reasonable, and have been dropping.

By the way, Moto is apparently working on a fast 8Kx24 SRAM chip designed
with the 56K in mind.

>Decoding...
>
>I thought it would be difficult to decode the X, Y and P lines, but
>there is a simple solution: just use a three to eight decoder....
>The delay time that this chip adds is another thing you must account
>for if you want to use no wait state SRAMS.
>

If you have the programming tools available, I'd recommend using GALs since
1) they are very fast, 2) it reduces the amount of LSI/MSI logic laying
around on the board, and 3) you can reprogram them (they're electrically
erasable) whenever you want to remap the RAM/ROM/IO (you can even store
multiple `maps' internally and select the one you need dynamically from the
56K, host, or through jumpers).  GALs really save you a *lot* of time,
headaches, board space, and cost in this application.

>Todd Day  |  todd@ivucsb.sba.ca.us  |  ivucsb!todd@anise.acc.com

Good info, Todd!

Mike