Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!visix!amanda From: amanda@visix.com (Amanda Walker) Newsgroups: comp.sys.mac.hardware Subject: Re: Memory speeds can be critical (was: SIMMs for IIsi - what do I need?) Message-ID: Date: 18 Dec 90 19:10:59 GMT References: <110992@convex.convex.com> <2915@ux.acs.umn.edu> Organization: Visix Software Inc., Reston, VA Lines: 57 All right, now I'm really confused, and I've built DRAM circuitry... In article <2915@ux.acs.umn.edu> dhoyt@vx.acs.umn.edu writes: >Imagine you have a chip that is rated at 120ns with a 120ns driver. >(Greatly simplifying) you will have a signal that looks like this > +---+ +---+ > | | | | > ----+ +-----------------------+ +---------------------- > 0 ns Time-> 120ns > >I.e. the amount of time that the signal takes to get through the chip is >roughly 120ns. Not even close. There is no signal "going through the chip." The "speed" of a dynamic RAM which is usually quoted (and which is printed on the chip) is not a propagation delay. It is the Row Access Time, usually abbreviated Trac, and refers to the guaranteed maximum time it will take for the data outputs to become stable, or the data inputs to be properly latched, after the Row Address Strobe (RAS) is asserted. In simple terms, this is how long you have to wait before looking at the outputs to be sure they are stable. They will actually become stable at some time before that, but until RAS is negated, the outputs will just sit there. The length of the RAS pulse is a function of the memory addressing circuitry (in this case, the Mac), not of the SIMM. There are no strobes or other signals generated by the DRAMs, besides the data bits themselves, and those data bits are held on the bus until the Mac tells the chip to let go, as it were. Once again, the Mac can't tell when the data is ready; it just waits the rated amount of time and latches the data then. If the outputs settle 20ns early, it doesn't care. They'll still be there until it gets done with them. >Now this is all a gross generalization and the real world is much more >complex, Indeed. >but hopefully this will give some idea why it's a bad idea to >mix-and-match willy-nilly. Nope. Sigh. I have no idea what you're talking about, but it sure isn't DRAM. I still want to hear an explanation that's either quoted from the tech note or straight from one of the hardware dudes who designed the memory system in question. I mean, I don't even know how to build a dynamic memory subsystem that could tell the difference, even on purpose... I've even got a IIsi at home--I'll see if I can scrape up some mixed-speed SIMMs and actually try this out. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "Generally you don't see that type of behavior in a major appliance." --Ghostbusters