[SI-LIST] Re: Questions on Reference Planes for DDR3 signals
- From: "Loyer, Jeff" <jeff.loyer@xxxxxxxxx>
- To: "si-list@xxxxxxxxxxxxx" <si-list@xxxxxxxxxxxxx>
- Date: Thu, 21 Jun 2012 17:12:48 +0000
Has anyone else tried the experiment of using VDDQ as the reference plane
instead of ground on an actual motherboard design? If so, can you share your
results?
When we tried it on a microstrip channel, we saw margins degraded dramatically,
but not for the reasons cited below. Noise on the VDDQ plane was the only
predictor of degraded margin. No amount of TDR'ing, TDT'ing, measuring xtalk,
etc., could show a dramatic difference between channels routed w/ GND
referencing vs. those w/ VDDQ referencing. I could see measurable differences,
but not enough to account for the dramatic margin degradation.
What was dramatic was the noise on the VDDQ plane that was then introduced on
the data lines, degrading their margin appreciably. Simulations backed up
this finding - w/o power supply noise, margins weren't degraded significantly.
With power supply noise, margin degradation on a per-bit basis mimicked our
measurements extremely well. The biggest question for me was whether we'd
introduced an abnormally noisy VDDQ plane, since it had to be "kludged" into
the design (pinouts are tailored towards GND referencing). But, we're not sure
this was unique to our design - we think you would do that if you tried to use
VDDQ referencing on most actual designs. The pinouts favor GND referencing -
you end up introducing a large floating VDDQ plane if you try to use it as
reference. I'm afraid this is hard to explain w/o pictures - sorry.
Bottom line is that I think that you'll degrade your margin appreciably
(dramatically) by using VDDQ referencing on microstrip, but not for the reasons
cited. I'd love to see data from others who have actually performed the
experiment.
Similar findings for stripline, margins reduced dramatically if VDDQ-only
referencing was used, though we didn't perform the same intense analysis to
find the root cause, though I suspect noise on the VDDQ planes as the primary
culprit. Again, the pinout forced the introduction of VDDQ referencing to be
an awkward (non-ideal) design, so I'm not sure this is avoidable in real
designs.
Margins were reduced on asymmetric stripline when the far reference plane was
changed from GND to VDDQ, though not near as dramatically; here too I suspect
noise on the VDDQ plane as the primary culprit.
I look forward to hearing what work others have done to validate this design
rule on actual designs, vs. theoretical studies.
Also, could someone please clarify the comments about "clock"? Are you talking
about the strobes? If so, I don't know how you would treat those significantly
different (reference-wise) than the data lines, since they are positioned in
the middle of the data lines. To cut out a dedicated reference plane for those
would seem to be extremely problematic (if not pathological), or am I missing
something? Aren't you forced to treat them very similarly to the data lines?
Thanks in advance,
Jeff Loyer
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Ken Wyatt
Sent: Thursday, June 21, 2012 7:18 AM
To: Hirshtal Itzhak
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Questions on Reference Planes for DDR3 signals
Itzhak,
Follow Steve advice.
The only thing I might add is to be sure to extend the return planes along the
entire data/address/control pathway. Avoid crossing gaps or jumping from one
reference plane to another along the return path. We designers often forget
that it's the signal -current- that's important. Where does the return current
want to go as it returns to the source? High frequency (> 10 kHz!) currents
tend to flow on the path of -least impedance-. We need to make it easy by
avoiding the crossing of gaps/slots in reference planes and jumping from one
reference to another.
Also, avoid running clock lines along the edge of your PC board - keep them
internal. You might also lay them out first, so they are direct and -short-
Cheers, Ken.
_______________________
Kenneth Wyatt
Wyatt Technical Services LLC
Woodland Park, CO
Email Me! | Web Site | Blog
The EMC Blog (T&M World)
Subscribe to Newsletter
Connect with me on LinkedIn
On Jun 21, 2012, at 2:39 AM, steve weir wrote:
>
> Hirshtal, this all amounts to reducing signal disturbance.
> Unfortunately, this is another case of: "It all depends." The data
> signals constitute the higher data rates as well as the greater number
> SSOs, so they deserve more care than the A/C signals. However, if you
> want reliable operation at speed, reasonable care must be employed
> with both. You have a few basic options:
>
> 1. Follow a proven topology exactly as though your life depends on it.
> Pray that the gods of reference designs will reward your dedicated
> obedience by blessing your effort.
>
> 2. Develop and evaluate design rules that are suitable to your
> particular situation. Tool sets are available to evaluate different
> topologies, such as from Si-Soft. If you don't have the tools, the
> budget, or the time, then you can lean on an outside service to do
> this for you.
>
> 3. Try to develop rules ad-hoc without checking and hope that Murphy
> does not decide to amuse himself at your expense. The more
> conservative the rules you set, the more likely you can save yourself
> the wrath of Murphy.
>
> Slides 14 and 15 of this presentation available on my web-site
> illustrate what you face with different routing topologies:
> http://www.ipblox.com/pubs/SVCEMC_May_2005/capacitor_placement_public_
> b.pdf
>
> A couple of comments: Memory packages and DIMMs reference data lines
> to Vss. DIMMs reference A/C to VDDQ. This was done to support low
> layer count PCBs. It works. You will avoid introducing extra noise
> and cross-talk by extending those references in your channel end to end.
> What your memory controllers reference varies. Any reference change
> you introduce will inject energy between the the references used.
> This can be handled, but requires work and more analysis. And unless
> the design is low performance, it usually imposes more cost for equal
> performance.
>
> A final note: Always treat clock with the utmost care. Barring some
> terrible cost impact a continuous Vss reference is a good way to treat
> clocks.
>
> Steve
> On 6/21/2012 1:42 AM, Hirshtal Itzhak wrote:
>> Hello all,
>> I've been looking at DDR3 layout guides from Micron and from some
>> manufacturers of DDR3 controller devices and haven't found a clear
>> recommendation for how to deal with the issue of reference planes for DDR3
>> interfaces in a stripline configuration. Also, there are some other
>> "reference-plane" issues which I hope someone can clarify.
>>
>> So here are the questions I haven't found a clear answer for:
>>
>> (1) Almost all recommendations that I've found are
>> to route data-group signals "adjacent to a solid GND Layer". Can I,
>> therefore, route them adjacent to both a GND and a Power plane in a
>> stripline configuration? Does it matter if the stripline is symmetric
>> (relative to the 2 ref planes) or not?
>> (2) Almost all recommendations that I've found are
>> to route address/command/control signals "adjacent to a solid Power or GND
>> Layer". Can I route them adjacent to a Power plane with a voltage different
>> than the DDR3-1.5Volt VDD?
>> (3) If DDR-VDD is required, can I use another
>> solid Power plane as the other plane in stripline configurations (provided
>> the 1st plane is VDD)?
>> (4) What reference plane is recommended for the
>> Clock pair? Micron, for example, doesn't say anything on this matter, but
>> some other manufacturers recommend using only a GND plane. Is this true, as
>> far as you know?
>>
>> Thanks in advance for your help!
>>
>> Itzhak Hirshtal
>> Elta Systems
>>
>> 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 forum is accessible at:
>> http://tech.groups.yahoo.com/group/si-list
>>
>> 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
>>
>>
>>
>
>
> --
> Steve Weir
> IPBLOX, LLC
> 150 N. Center St. #211
> Reno, NV 89501
> www.ipblox.com
>
> (775) 299-4236 Business
> (866) 675-4630 Toll-free
> (707) 780-1951 Fax
>
> All contents Copyright (c)2012 IPBLOX, LLC. All Rights Reserved.
> This e-mail may contain confidential material.
> If you are not the intended recipient, please destroy all records and
> notify the sender.
>
> ------------------------------------------------------------------
> 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 forum is accessible at:
> http://tech.groups.yahoo.com/group/si-list
>
> 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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
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:
