25 Sep
2005
25 Sep
'05
9:59 p.m.
When connecting DRAM chips to the pins of a SIMM (i.e. laying out the
traces) does it matter if the order of the address and data lines is
preserved? In other words, does A0 on the SIMM need to connect to A0
on the chip, and A0 on all the other chips as well? These are old
DRAM, such as FPM or EDO, used in 30 pin SIMMs. Nothing new and
fancy like SDRAM.
I believe the answer is no. But I know from experience that there
are sometimes odd scenarios that are easily overlooked, so I figured
I'd access the shared experience and knowledge here.
It's a lot easier to layout the PCB for the SIMMs, if I don't
preserve order. And it shouldn't matter, because anything that gets
stored at address X should come back out on a read to address X.
The only circumstance I can think of that could cause a problem is if
the RAM has some kind of sequential read mode where consequeutive
addresses are expected. Reading the datasheet, I don't see a mode
like that. The closest thing is a burst mode where the Row address
stays constant and a series of Column addresses are supplied, but
that should work just fine, I think.
So, any gotchas to disordering the address and data pins between the
SIMM, and the chips and from chip to chip?
Jeff Walther
26 Sep
26 Sep
2:41 a.m.
When connecting DRAM chips to the pins of a SIMM (i.e.
laying out the
traces) does it matter if the order of the address and data lines is
preserved? [...]
What about refreshes? (This is a question, not a challenge; I do not
know enough about how dynamic RAM refresh works to know whether this
really is relevant. But it seems to me that it might be.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:18 a.m.
der Mouse wrote:
Just that all of them gets refeshed in the alloted time.
Note they just have to be read for refesh. Still you better
check the data sheets if you got them for the fine print.
When connecting
DRAM chips to the pins of a SIMM (i.e. laying out the
traces) does it matter if the order of the address and data lines is
preserved? [...]
What about refreshes? (This is a question, not a challenge; I do not
know enough about how dynamic RAM refresh works to know whether this
really is relevant. But it seems to me that it might be.)
11:04 a.m.
Jeff Walther wrote:
When connecting DRAM chips to the pins of a SIMM (i.e.
laying out the
traces) does it matter if the order of the address and data lines is
preserved? In other words, does A0 on the SIMM need to connect to A0 on
the chip, and A0 on all the other chips as well? These are old DRAM,
such as FPM or EDO, used in 30 pin SIMMs. Nothing new and fancy like
SDRAM.
I believe the answer is no. But I know from experience that there are
sometimes odd scenarios that are easily overlooked, so I figured I'd
access the shared experience and knowledge here.
It's a lot easier to layout the PCB for the SIMMs, if I don't preserve
order. And it shouldn't matter, because anything that gets stored at
address X should come back out on a read to address X.
The only circumstance I can think of that could cause a problem is if
the RAM has some kind of sequential read mode where consequeutive
addresses are expected. Reading the datasheet, I don't see a mode like
that. The closest thing is a burst mode where the Row address stays
constant and a series of Column addresses are supplied, but that should
work just fine, I think.
Static column mode DRAMs don't care about the mapping.
Burst mode DRAMs could be a problem. IIRC, the burst length for older DRAMs was
two to four sequential addresses, obtained by internally accessesing consecutive
DRAM locations without having to wiggle the address lines. This mode was
typically used for filling an x86 cache line. Thus you should at least ensure
that A0 and A1 of the SIMM get wired to A0 and A1 of the DRAM. The others are
free to remap. If you know your application doesn't use this mode of operation,
then remap any/all of the addresses.
One last thing. There were DRAMs that used a different number of address lines
for RAS than for CAS. For instance, say you have a 128K bit DRAM (for instance,
often sorted out from failing 256Kb DRAMs) arranged as 256 rows by 512 bits per
row. There would be 9 address lines on the DRAM, but one of the address lines
(probably A8) would need to be distinguished and mapped consistently.
As a disclaimer, I have designed, implemented and shipped a number (10?) of DRAM
controllers, both in TTL and in ASIC forms, but the most recent to ship was
about 1991, so some details might have faded.
6:43 p.m.
When connecting DRAM chips to the pins of a SIMM (i.e. laying out the
traces) does it matter if the order of the address and data lines is
preserved? In other words, does A0 on the SIMM need to connect to A0
on the chip, and A0 on all the other chips as well? These are old
DRAM, such as FPM or EDO, used in 30 pin SIMMs. Nothing new and
fancy like SDRAM.
Well, obviously for plain read and write, you can scramble the address
and data lines any way you like (provided, if there are separate DIn and
Dout, that you keep those consistent).
There are a few possible problmes.
1) Refresh. If you use CAS-only refresh, then it doesn't matter at all,
because the DRAM chip generates the refresh addrees. If you use RAS-only
refresh, then it shouldn't matter as to the order uless only some of the
address lines are used for refresh. For example, some 64K DRAMs (8
address lines) only used the lower 7 for refresh, then you would have to
keep A0-A6 on the system going to A0-A6 on the RAM _in some order_, and
keep A7 linked to A7.
2) If there are any clever multiple read modes, it may well be that you
can do things change the bottom 2 address bits without doing a full
memory cycle and effectively read 4 locations per full memory cycle. If
the RAMs support something like that _and your machine uses it_, you'd
have to keep A0 and A1 wired to A0 and A1 of the DRAMs.
-tony
6870
days inactive
6870
days old
4 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
frustum＠pacbell.net -
mouse＠Rodents.Montreal.QC.CA -
trag＠io.com