Date: Mon, 26 Sep 2005 08:18:24 -0600
From: woodelf <bfranchuk at jetnet.ab.ca>
Subject: Re: SIMM, Address Lines Order?
der Mouse 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? [...]
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.)
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.
I do have the data sheets. I am planning to use the KM44C16100 from Samsung.
Looking at the various refresh options in the datasheet:
1) The RAS only, and Hidden Refresh cycles involve a Row address
supplied on the address lines. So, unless there's some undocumented
requirement that these address be supplied in a particular order, I
don't think that will cause a problem. However, I recognize that
sometimes datasheets (and documentation in general) assume general
knowledge about the topic. So if there is some implicit assumption
about the addresses supplied during a refresh, I'd appreciate someone
explaining it to me.
2) During CAS before RAS refresh, the address lines are listed as
'don't cares'.
In other weirdness, I never saw the "der Mouse" reply to my posting,
so I checked the cctalk archives, on a hunch. There are several
replies to my posting in cctalk which never appeared in the cctech
digest or archive. Is this normal? How are the two lists organized
wrt each other? Does cctalk see all the cctech postings, but not
vice versa? It creates difficulties if folks on cctalk reply to
cctech postings by emailing to cctalk. Is it assumed that everyone
is subscribed to both? I am happy to adjust as necessary. I just
don't understand the arrangement, yet.
* Jim Battle frustum at
pacbell.net writes:
Burst mode DRAMs could be a problem.
I mis-wrote. These DRAMs have a Fast Page mode--not a burst mode. I
was mislead by discussion of burst reads in "The Guide to the
Macintosh Family Hardware" but I believe those burst reads are
between the CPU and the memory controller chip in the IIfx.
I should have written Fast Page mode, during which a Row address is
supplied with the RAS, then a series of Column address is supplied
while strobing the CAS for each change in Column address. Because
the addresses are explicitly supplied, I don't think that reordering
the address pins should cause any problems. A FP read will still
stay within the same page (row address) for a given DRAM chip.
One last thing. There were DRAMs that used a
different number of
address lines
for RAS than for CAS.
Good point. These are 12 X 12, 16M X 4 chips, so that should not be
an issue. If they were 13 X 11, I'd need to make sure that the upper
two address line orders were preserved?
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.
The computer for which I'm building the SIMMs was released around
1991, so there's a nice symmetry there.
* Allison ajp166 at
bellatlantic.net writes:
Tim Olmstead wrote a Z80 Dram interfacing manual
Google turned it up. Thank you for pointing it out.
* Dwight K. Elvey dwight.elvey at
amd.com writes:
Only that the first address lines that are used for
refresh
need to be grouped. As example for a 128 cycle refresh, that would
be that one could mix any of the A0-A6 lines. This is because
of how the blocks of RAM are accessed and then selected by
a mux to the output.
Can you elaborate on this. I must be missing some key bit of
information about refresh. I get that 7 address lines are 128
addresses or blocks of RAM if one is just talking about Row
addresses. But how does that mean that some address lines can be
mixed and others not?
Is there a refresh mode where multiple blocks are chosen at one
time--where the upper address bits are defined, but the lower bits
are don't cares? That's not mentioned in the datasheet, but just
because it isn't mentioned, doesn't mean it isn't assumed.
I've been trying to find out which refresh scheme the IIfx uses, but
haven't found it in the limited documentation I have here. I have a
feeling I've read it somewhere...darn it.
Thank you for all the comments and help folks,
Jeff