Steve, Have you verified that memory packages reference data lines only to Vss? The memory pinout suggests that data lines are referenced to both Vss and Vddq. Thanks, Vinu On 06/21/2012 01: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 >> >> >> > ------------------------------------------------------------------ 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