[sci.electronics] DRAMS

curtis@cit-vax.Caltech.Edu (shan Curtis) (05/24/87)

References:



If I'm using DRAMS (Fujitsu MB81257-12) only in Read, Write and CAS-before
RAS refresh, it would appear from looking at the  timing diagrams, that 
the Q line (data out)is always hi-Z until read cycles.  Is it ok to connect
the Q and D lines together and directly to the bus, thereby avoiding having
to use buffers?  Thanks for the help in advance.  

Curtis
ccl@juliet.caltech.edu
curtis@cit-vax.caltech.edu

grr@cbmvax.cbm.UUCP (George Robbins) (05/24/87)

In article <2804@cit-vax.Caltech.Edu> curtis@cit-vax.UUCP (Curtis Ling) writes:
> 
> If I'm using DRAMS (Fujitsu MB81257-12) only in Read, Write and CAS-before
> RAS refresh, it would appear from looking at the  timing diagrams, that 
> the Q line (data out)is always hi-Z until read cycles.  Is it ok to connect
> the Q and D lines together and directly to the bus, thereby avoiding having
> to use buffers?  Thanks for the help in advance.  
> 
> Curtis  ccl@juliet.caltech.edu

As a general rule, you can tie data in and data out together as long as your
write signal is asserted before CAS.  Whether you can tie the rams directly
to a bus is more complicated, but as long as you understand that CAS is, in
effect, an output enable signal, you can avoid conflicts.  If you are planning
on connecting to some kind of "external" microcomputer bus, you will probably
need some kind of buffers for reliable operation.  Also, do not neglect series
termination resistors on address and control lines, and proper layout and
decoupling.  DRAM's *can* be a real pain in the ass unless treated with the
proper degree of respect.
-- 
George Robbins - now working for,	uucp: {ihnp4|seismo|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

henry@utzoo.UUCP (Henry Spencer) (05/26/87)

> ...  Also, do not neglect series
> termination resistors on address and control lines, and proper layout and
> decoupling.  DRAM's *can* be a real pain in the ass unless treated with the
> proper degree of respect.

In case people are interested...  A while ago an acquaintance of mine asked
for advice on designing a DRAM memory board for his 6809 box.  Herewith some
excerpts from what I sent him [NB prices mentioned are out of date].  Any
corrections are welcome; I'm not a pro at this.

Dynamic memories unfortunately aren't the simplest chips to cope with.
They are definitely designed for people who are willing to put up with all
manner of annoyance for the sake of minimum price and maximum density.
If you're really short on experience, you might consider putting together
a board with 8Kx8 static RAMs first; it will be neither as cheap nor as
capacious as a dynamic board, but it will be much more forgiving...

For the fractional-megabyte range, though, dynamic RAMs are the only choice.
An 8Kx8 static has twice the price and three times the board area of a
256Kb dynamic which has four times the capacity.

... the actual memory chips aren't going to be a
major cost item.  If you buy from a relatively cheap source (one that I
and others highly recommend is Microprocessors Unlimited in Oklahoma --
cheaper than local sources, although a bit of extra hassle because you
have to handle Customs yourself), the memory chips come in at maybe US$25
per quarter meg.  Since it must be a multiple of 8 wide, 8x32KB (i.e., a
quarter meg) is the quantum of size.  There is not much point in using
smaller chips; the cost difference is not significant any more, and if
anything the 256Kb ones are more reliable and better behaved.

Getting it reliable is not too difficult given solutions to the problems
of timing and refresh, careful electrical design, and a relaxed environment
where you aren't pushing things to the limit.  If I'm not mistaken your box
will have something like a 1 MHz 6809, which is relaxed by anyone's rules.
That does make life a lot simpler.

You're going to have to think about when to do refresh.  You can do it in
software if you're careful, but particularly if you're running an existing
operating system you probably don't want to try that.  The alternatives are
to tighten up the timing a bit and use the first half of the 6809's cycle
to do refresh (since it doesn't need to look at the memory then), or else
just butt in occasionally and put the 6809 on hold momentarily.  Just how
you solve the timing problem will influence this...

Careful electrical design is a must for these things.  The key fact is that
dynamic RAMs must be treated, in many ways, as *analog* parts.  So it all
has to be just right, unlike normal digital stuff where you can get away
with a lot.  You need a decoupling capacitor, say 0.33uF, for *every* memory
chip, with leads as short as possible, plus larger capacitors well-sprinkled
over the board.  You need a good grid of power and ground lines to match.
If using a PC board, make those traces wide; if using hand wiring, use heavy
gauge wire.  When in doubt, use more capacitors and thicker wire; power
problems will make the whole thing impossible.  Put series damping resistors
(say 22 ohms) in every wire running from TTL to a DRAM, so edges don't fall
too rapidly and undershoot -- DRAMs can't take much undershoot.  Stuff coming
out of a DRAM isn't a problem that way, but beware of the limited drive 
capabilities of DRAM outputs.  Don't try to drive a control signal on a
whole pile of DRAMs with one TTL output; say 8 DRAM inputs max per TTL output.
Put your drivers in the middle of the DRAM array, not off in a corner.  If
your construction technique permits a ground plane (one side of board a
solid sheet of copper for ground), do that.

If all this sounds unnerving, that's just as well:  the way to solve such
problems without complexity is beat them to death with a sledgehammer,
not to try to get away with the minimum possible.  You want to be so careful
about things like power and ground that you never have to worry about them
later.  Debugging that sort of problem is hard, so best to avoid the need...

...Just about everyone seems to
use either delay lines or counter-based state machines for the timing signals
proper...  Delay lines are hard to get in small quantities.
It would also be worth looking at what sort of timing signals you have on
your bus already; sometimes there are enough edges there...

If you are using sockets -- a good idea -- get good ones.  I've heard
enough horror stories about obscure problems tracked to poor sockets that
I normally buy only machined-contact sockets with gold-plated contacts.
(What the plating is on the outside, something you also get to choose, is
pretty irrelevant; tin is cheaper than gold.)  The wart is that they are
pricey:  the bill for the sockets will be a noticeable fraction of the bill
for the DRAMs.

DRAMs in general, and 256Kb RAMs in particular, are VERY VERY sensitive to
static.  This is another area where absolute paranoia is the simplest method.
Microprocessors Unlimited recommends the following:  Lay down a sheet of
aluminum foil on your worktable.  Put your board down on that.  (Obvious
problems here if there is something electrically live on your board, like
a battery-backed clock, though.)  Put the tubes containing the ICs down on
the foil.  Then put one elbow down on the foil, firmly, and keep it there
as you install the chips into the board.  No further problem.  Simpler and
probably better than messing around with commercial wrist straps etc.
-- 
"The average nutritional value    Henry Spencer @ U of Toronto Zoology
of promises is roughly zero."     {allegra,ihnp4,decvax,pyramid}!utzoo!henry

phil@amdcad.AMD.COM (Phil Ngai) (05/26/87)

In article <2804@cit-vax.Caltech.Edu> curtis@cit-vax.UUCP (Curtis Ling) writes:
>
>If I'm using DRAMS (Fujitsu MB81257-12) only in Read, Write and CAS-before
>RAS refresh, it would appear from looking at the  timing diagrams, that 
>the Q line (data out)is always hi-Z until read cycles.  Is it ok to connect
>the Q and D lines together and directly to the bus, thereby avoiding having
>to use buffers?  Thanks for the help in advance.  

This kind of thing can work, as I have done it in a product. Note,
that one of the claimed features is "Common I/O capability using
'Early Write' operation". 

Some important considerations are

1) are you doing early write cycles? If you are doing late writes, the
RAM will probably experience a bus collision with the device doing the
write until you assert *W. This is because the RAM doesn't know you're
not doing a read cycle until *W is activated.

2) Also check the load capacitance presented to each of the drivers on
the data bus.  DRAMs generally drive 100 pF and present about 7 pF on
each of D and Q. 

3) All the usual stuff about good bypassing, transmission line
effects, motherhood and apple pie. If you only have 16 devices or so
you can afford to be somewhat sloppy (that's the number I used and the
signals were super clean) and with 64 you have to be more careful.
There are special RAM drivers with series termination resistors in the
IC, these provide faster drive with more symmetric rise and fall
times. Look for the 2965 or 2966. 

What is this doing in rec.aviation?
-- 
Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or amdcad!phil@decwrl.dec.com