[SI-LIST] Re: The necessity of Pull-up resistors in DDR2

  • From: "Marc Humphreys" <mhumphreys@xxxxxxxxxxxxxxxxxxx>
  • To: "'Hirshtal Itzhak'" <ihirshtal@xxxxxxxxxx>, <twesterh@xxxxxxxxxx>
  • Date: Mon, 1 Feb 2010 18:40:39 -0500

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
  

Other related posts: