[SI-LIST] Re: Decoupling in DDR3 Applications
- From: Heyfitch <heyfitch@xxxxxxxx>
- To: Hirshtal Itzhak <ihirshtal@xxxxxxxxxx>
- Date: Fri, 19 Feb 2010 00:51:24 -0600
Itzhak,
the pinout of a 240-pin DIMM connector is identical for both U- and RDIMM
(aside a few reserved-but-unused signals). All ACC (Address/Cmd/Ctrl) signal
come through the middle section of the connector where they are interspersed
with the 22 VDD pins. There are no VSS pins there at all. So, it makes
perfect sense to keep these signals referenced to VDD plane(s) as they go on
to DRAMs. The DQ and DQS/DQS# signals come through the DIMM connector mixed
among the VSS pins only. It makes sense - and easier too - to route them
referenced to VSS plane(s) on the DIMM. If you are forced to reference
these ACC signals to VSS anywhere along their run, place lots of small
bypass caps around where the signals change their reference plane from VDD
to VSS.
Also, DRAM uses VREFCA with ACC signals. Inside the DRAM package, VREFCA is
routed together/among the ACC signals and VDDQ, - all crowded toward one
end of the die, - be it wirebond or RDL die. The intent is to have external
noise couple as common mode onto both, the signal and its reference. [It is
another longer, tangential discussion about whether this intent is
realizable.] Hence, if you have to run ACC signals referenced to VSS, you'd
have to place extra bypass caps between VDD and VSS around each DRAM.
Similarly, VREFDQ bondwire / RDL is mixed among/with the DQ/DQS signals and
VSSQ inside the DRAM package / die. Hence, for the sake of return path
continuity, you'd want to keep DQ/DQS signals referenced to VSS all the way
from the connector edge to a DRAM.
So, now that you have the reasoning for the recommended referencing choices
for ACC and DQ/DQS to VDD and VSS respectively, on to you question about the
VTT. Steve Weir has already answered it. You want to make the VTT rail, to
which ACC are terminated, and VDD, to which they are referenced - for the
reasons discribed above, - equivalent in the RF sense so that to close the
return path loop. At the DIMM ends, where the Rtt termination resistors sit
on the VTT shape, vendors normally have some VDD/VSS bypass caps too. If you
are designing your own, non-JEDEC Raw/Card-X DIMM, and aren't too stingy
with bypassing VDD/VSS at the dimm ends, you may as well decouple VTT to VSS
(or to both VS and VDD). Although indirectly, the VTT rail would still be
well decoupled to VDD too.
The same logic should apply to SoDIMM, although I have not dealt with it.
-Vadim
On Thu, Feb 18, 2010 at 6:57 AM, Hirshtal Itzhak <ihirshtal@xxxxxxxxxx>wrote:
> Hello Experts!
>
>
> I found out that the Unbuffered DIMM Design Specification 21C Page
> 4.20.19-30 (Revision 1.01 Nov 2009) recommends to decouple VTT by
> decoupling capacitors to VDD. VREFCA has the same recommendation.
>
>
>
> On the other hand, on the same page, VREFDQ is recommended to be
> decoupled to VSS.
>
>
>
> Also, I couldn't find any specific recommendation for the decoupling
> voltage in the Unbuffered SO-DIMM Reference Design Specification 21C
> Page 4.20.18-28 (Revision 1.0 Feb 2009).
>
>
>
> Does anyone happen to know why decoupling is recommended to be done to
> VDD rather than VSS in all cases? It seemed to me that VSS was always
> the preferred voltage to decouple to. And if there's a good reason for
> not doing it, then why the differences between the various voltages and
> the two DIMM specs?
>
>
>
> Also, is there a difference in regard to embedded (non-DIMM)
> applications?
>
>
>
> 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
>
>
>
------------------------------------------------------------------
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:
