Itzhak, To your last point - about "supposed to work", it would be insightful to understand what routing rules are assumed and your memory configuration. If your design decisions are based on vendor supplied guidelines take them with a grain of salt. Most design guidelines come as an afterthought to the design of evaluation platforms, and although the vendor may have delivered a functional demo board, the guidelines for such should not be relied on as a golden reference for your projects design rules. (This topic is meat for a separate thread. ) For an un-buffered memory-on-board design, 200Mhz may not seem much of a challenge, assuming SI is validated. However, on nearly every similar project I've designed and timed out for my clients, you'll find you can improve your timing margins on ADDR/CMD significantly by delaying your clock edge with respect to the ADD/CMD signals with 8+ loads - in most designs such adjustment has been required to guarantee timing margin especially for the slow corner. A common observation on such designs, assuming shortest possible matched data lanes (match to 100 mils), shortest ADD/CMD ( matched to 1"), you'll need to add a minimum of 3" of etch on your clock lines to cover the slow corner case. I find that 3" will by no means center the clock, but is fairly achievable length (routability wise) to add to most designs, and will buy you ~1/4ns of needed setup margin. The relationship between CK and DQS is fairly loose and you have to work really hard to break it assuming the routing constraints mentioned above, but always check that the numbers work out. As an aside: For those in the lab suspecting a timing issue, adding some additional capacitance to the end of clock line(s) is a quick and dirty way to experiment with ADD/CMD timing issue. A scope would be required to check relationship between CK and ADD/CMD before and after. As Todd recommends, you really need to leverage both an SI and timing methodology to design the interface. The multitude of options, from driver technology, drive strength, termination strategies, topologies etc. gives one a great advantage in designing the most efficient design possible, allowing one to make trade-offs between real estate, device count and power taken into account, in addition to validating the design in the first place. The resulting rule sets that your simulations dictate can then be reused across multiple designs for the same memory configuration, remembering that potential crosstalk issues need to be looked at separately for each routed implementation through the use of post-route analysis. Finally, to go full circle back to your original question on DDR2 termination. You may be (unpleasantly) surprised at how much difference the margins can change between a net terminated to VTT and one that uses series terminations or none at all. For DDR2/400 memory-on-board designs, I've had great success using series termination instead of terminating to VTT on ADD/CMD nets provided you can place the memory close to the CPU and keep etch lengths ~4" or less and compensate for the difference between CLK loading and ADD/CMD loading. The end result helped with both board area and power which often is a critical system constraint to meet, but assuming similar timing between the two is a mistake. Marc _____ From: "Hirshtal Itzhak" <ihirshtal@xxxxxxxxxx> Sent: Monday, February 01, 2010 4:04 AM To: twesterh@xxxxxxxxxx Subject: [SI-LIST] Re: The necessity of Pull-up resistors in DDR2 Ted, You're right regarding the timing issue. The reason I'm quite sure about timing is that the bus is supposed to work with the low frequency of 200MHz Clock Itzhak -----Original Message----- From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx] Sent: Sunday, January 31, 2010 4:52 PM To: Hirshtal Itzhak Cc: si-list@xxxxxxxxxxxxx Subject: Re: [SI-LIST] The necessity of Pull-up resistors in DDR2 Hirshtal, Signal integrity is all about getting an adequately clean signal to a receiver input in time to meet setup and hold requirements. DDR2 drivers have active pullup/pulldown stages; you don't _need_ a resistor in the circuit to drive the signal high and low. DDR2 address and control lines are often multi-drop, termination is used to maintain signal integrity by controlling reflections. The signal is terminated to VTT (=VDD/2) to minimize duty cycle distortion. If your signal integrity simulations suggest termination isn't needed, it may not be. The important part is ensuring that you're extracting the correct interconnect delay from your simulations and figuring out what your timing margins are. This requires normalizing simulation waveforms to account for the driver's output timing and setup/hold/derating at the receiver, then computing the interface's voltage and timing margins. The statement "I get proper wavefoms" tells only half of the story. Termination reduces the signal swing and changes the interconnect delay; you have no way of knowing whether your interface will work without looking at timing as well. Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com Hirshtal Itzhak wrote: > Hello SI Experts > > > I've conducted some pre-layout simulations on a DDR2 bus connected to > on-board DDR2 devices. > > > > I found out that I get proper waveforms even if I don't use pull-up > resistors on the Address & Control lines. > > > > I wonder if this is an acceptable result! I've always been using those > pull-up resistors in previous designs. > > > > Is it a mandatory requirement to have a pull-up resistor to VTT on these > lines? > > If I don't use them, how is the dynamic current supposed to be supplied > to the lines? > > > > What could go wrong (if at all) if I don't include them in the design? > > > > Thanks > > > > Itzhak hirshtal > > > > > > The information contained in this communication is proprietary to Israel Aerospace Industries Ltd., ELTA Systems Ltd. > and/or third parties, may contain classified or privileged information, and is intended only for > the use of the intended addressee thereof. If you are not the intended addressee, please be aware > that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. > If you receive this communication in error, please notify the sender immediately and delete it from > your computer. Thank you. > > > This message is processed by the PrivaWall Email Security Server. > > > > > ------------------------------------------------------------------ > To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field > > or to administer your membership from a web page, go to: > //www.freelists.org/webpage/si-list > > For help: > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > > > List technical documents are available at: > http://www.si-list.net > > List archives are viewable at: > //www.freelists.org/archives/si-list > > Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > > > This message is processed by the PrivaWall Email Security Server. The information contained in this communication is proprietary to Israel Aerospace Industries Ltd., ELTA Systems Ltd. and/or third parties, may contain classified or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. This message is processed by the PrivaWall Email Security Server. ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List technical documents are available at: http://www.si-list.net List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu ------------------------------------------------------------------ To unsubscribe from si-list: si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field or to administer your membership from a web page, go to: //www.freelists.org/webpage/si-list For help: si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field List technical documents are available at: http://www.si-list.net List archives are viewable at: //www.freelists.org/archives/si-list Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu