Thank you all for your replies. As always much appreciated. Best Regards Charles Grasso Compliance Engineer Echostar Communications Corp. Tel: 303-706-5467 Fax: 303-799-6222 Cell: 303-204-2974 Pager/Short Message: 3032042974@xxxxxxxxx Email: charles.grasso@xxxxxxxxxxxx; Email Alternate: chasgrasso@xxxxxxxx ________________________________ From: steve weir [mailto:weirsi@xxxxxxxxxx] Sent: Friday, August 04, 2006 6:02 AM To: Ihsan Erdin Cc: Grasso, Charles; mrose@xxxxxxxxxxxx; Edi.Fraiman@xxxxxxxxxx; Vinu Arumugham; si-list@xxxxxxxxxxxxx Subject: Re: [SI-LIST] Re: DDRAM BUS Testing Ihsan, in most systems we have many capacitors. In many of the more expensive systems, we also tend to have relatively thin power cavities tying capacitors and loads together. So, removing one cap for the sake of measurement yields a tolerable error that we can pretty much calibrate out once we consider the capacitor and IC distribution, and the composition of the plane cavity(s). As a matter of fact, if you are a disciple of Istvan's DET methodology, the impedance across the planes can be very uniform, at least in theory. In the ideal incarnation of that methodology, current disturbances go off to disturbance heaven at the cavity edge where the resistance of the DET network absorbs the noise, preventing it from reflecting back into the cavity. Now if your Charles who has to build boards where 4 layers is a luxury, the situation can be very different. There, the interconnect characteristic impedance has a great deal of variation depending on distance from any given bypass cap. Those applications present sometimes vexing PDS design and measurement issues. If there is any rock to stand on, it is very shaky. What I would like to emphasize is that looking at the planes even where you can, tells a potentially very different story than what we care about first, which is the die. Looking at the planes is valuable when trying to: 1. See if the power system is in real trouble. Whatever noise is on the planes there is more at the die. 2. Figure out how much cross pollution we get between ICs, 3. Assessing EMC issues, or 4. Assessing that always lively topic: referencing high speed signals to disparate reference planes. But if you want the full story you really want to know what the die sees. There is no good substitute. We know from models and measurement that disturbing power at the die in approximate order of noise magnitude 1. Alters timing, 2. Causes erroneous logic levels. 3. Causes metastable and / or false switching events 4. Damages the IC The jitter issues that you face have a myriad of contributing causes, one of which is noise coupled onto the PLL supply voltage rail. Al Neves and Ransom Stephens can and do keep people busy for days explaining: the causes, how to find them, and how to correct / mitigate them. Regards, Steve. At 04:33 AM 8/4/2006, Ihsan Erdin wrote: Steve, I agree with your comments about the 5% tolerance. Despite occasional references in some research papers, it's a long-time outdated and useless figure of merit for contemporary designs. If my design couldn't meet it I'd throw it in the garbage without further tests. My observations with high speed designs are that the biggest impact of the noise is on the jitter and PLL operation. Especially for OC48 and higher telecom designs, the metric is much more complicated than +/- 5% tolerance on the VRM output. I think the research in this area should be directed to establish such a spec rather than beating this subject to death with copycat papers. I have a comment about your proposed measurement of noise coming from an IC. By removing the cap you change all the system dynamics. How useful could such a measurement be to represent the noise at that point? In other words, why should I care for how much noise I'd see at that point without the cap? Regards. Ihsan On 8/3/06, steve weir <weirsi@xxxxxxxxxx> wrote: Charles, 5% noise tolerance spec at the planes or caps will someday go the route of the infamous 50pF TTL load spec. It tells us only a little bit about what we really want to know, and that is what is happening at the die. The value of looking at a capacitor site or even a dedicated probe into the planes depends on what you want to know. First, even if the cap is very close to the chip, that location still tells you about power distribution near that locale. Even if the cap is right next to the IC connected through thin planes, or on the backside of the PCB, once we take the Z axis wild ride up into the chip package, the results can be very different. For example we can have dead quiet PCB planes and but dangerously noisy internal rails at the die. When Lee Ritchey complains about effects attributed to packages, that is the sort of symptom to watch out for: quiet PCB but horribly noisy die. All that interconnect from the die out works with the planes and bypass cap network to form a low pass filter than disguises what is happening at the die. If you want to know how much noise from a given IC is propagating out the planes, then you can sample the planes. Removing a capacitor and probing that site differentially provides a pretty good picture of what the planes see in that locale. As much as we would like to think of the planes as bedrocks of stability, they are far more volatile. In applications like yours where bypass caps have to do a higher proportion of the work than in boards with many layers, the value of that information is limited. If you want to know power supply noise across Vdd/Vss at the chip you really need to have a diff pair of Vdd/Vss from the die available. With core supplies you have no choice but to burn a Vdd/Vss pair. A pair of outputs is not a bad substitute for looking at noise on an I/O rail. As Mark pointed out, the signals that you bring out are subject to cross talk from whatever is near them in the package and the PCB. It doesn't matter what kind of signals they are. If you want to see what the ambient is for a given receiver, then you need to bring out that signal line and its Vref differentially. That can be very difficult as Vref is often short changed pin-wise. Regards, Steve. At 12:52 PM 8/3/2006, Grasso, Charles wrote: >Hi Mike=20 > >One thing that has vexed me in the past ( and continues >to vex me actually ) is the measurement of noise at the >decoupling cap. If the cap is some distance from the >chip - the the noise seen at the cap will not faithfully >represent the noise at the chip.=20 > >I'd like to ask you (and the folks on the reflector) >your opinion on the "best" location for measuring and qualifying >power noise. > >Thanks!! >=20 > >Best Regards >Charles Grasso >Compliance Engineer >Echostar Communications Corp. >Tel: 303-706-5467 >Fax: 303-799-6222 >Cell: 303-204-2974 >Pager/Short Message: 3032042974@xxxxxxxxx >Email: charles.grasso@xxxxxxxxxxxx; >Email Alternate: chasgrasso@xxxxxxxx > > >-----Original Message----- >From: si-list-bounce@xxxxxxxxxxxxx [ mailto:si-list-bounce@xxxxxxxxxxxxx <mailto:si-list-bounce@xxxxxxxxxxxxx> ] >On Behalf Of Michael Rose >Sent: Wednesday, August 02, 2006 5:07 PM >To: Edi.Fraiman@xxxxxxxxxx; Vinu Arumugham; si-list@xxxxxxxxxxxxx >Subject: [SI-LIST] Re: DDRAM BUS Testing > >Edi, > >I assume you're worried about signal integrity (not =3D >logic/functionality). Some troubleshooting tips to try: > >1. measure noise on the Vref lines for both the FPGA and memory. I don't >=3D >remember offhand but I belieive max is around 30mV. Micron Tech has a = >=3D >good DDR layout guide. > >2. carefully measure 1.8V or 2.5V Vcc and Vtt noise (use an AC-coupled = >=3D >50 ohm coax soldered directly to a local bypass cap site. > >3. Tie a probe to the DDR clock at the memory to trigger a high-speed = >=3D >scope (> 4GHz). It's nice to have software write a test loop to generate >=3D >various read and write bit patterns on the memory bus (especially =3D >alternating 00s and FFs). Probe each memory line and note under/over =3D >shoot, jitter, Tsu and Th. Remember you have to probe D/DQ at the memory >=3D >for write data and at the FPGA for read data. > >4. For Xilinx FPGAs, pay particular attention to undershoot (see their = >=3D >appnote where they suggest running the memory bus drivers at .3V below = >=3D >Vcc to prevent reverse biasing the clamps). > >I bet you'll find either excessive power supply noise, Vref noise, Vtt = >=3D >noise, or under/over shoot > >Good Luck, Mike > > >-----Original Message----- >From: si-list-bounce@xxxxxxxxxxxxx >[ mailto:si-list-bounce@xxxxxxxxxxxxx <mailto:si-list-bounce@xxxxxxxxxxxxx> ]On Behalf Of Fraiman, Edi >Sent: Wednesday, August 02, 2006 4:01 PM >To: Vinu Arumugham; si-list@xxxxxxxxxxxxx >Subject: [SI-LIST] Re: DDRAM BUS Testing > > >Yes, FPGA support JTAG. >But JTAG frequency is low. JTAG test wasn't working because we are out >of spec (minimum DDR operating frequency). > >=3D3D20 >Best regards, >=3D3D20 >Edi Fraiman > > > > -----Original Message----- > > From: Vinu Arumugham [mailto:vinu@xxxxxxxxx ]=3D3D20 > > Sent: Wednesday, August 02, 2006 3:54 PM > > To: Fraiman, Edi > > Subject: Re: [SI-LIST] DDRAM BUS Testing > >=3D3D20 > >=3D3D20 > > The FPGA does not support JTAG? > >=3D3D20 > > Thanks, > > Vinu > >=3D3D20 > > Fraiman, Edi wrote: > >=3D3D20 > > >Hi, > > >=3D3D20 > > > > > >I'm working on a design that includes FPGA with DDRAM controller =3D >and=3D3D20 > > >several DDRAM chips. The traces goings direct from FPGA to=3D3D20 > > DDRAM with=3D3D20 > > >necessary pulll up resistor to Vref. (SSTL interface)=3D3D20 > > without any debug=3D3D20 > > >connector. > > > > > >=3D3D20 > > > > > >Sometimes we have productions problems. It is very difficult to =3D >find=3D3D20 > > >what bit in bus between FPGA and DDRAM is shorted or disconnected. > > > > > >Could somebody give any tips how it's possible debug DDRAM busses =3D >in=3D3D20 > > >terms of production issues. > > > > > >=3D3D20 > > >=3D3D20 > > >Best regards, > > >=3D3D20 > > >Edi Fraiman > > >=3D3D20 > > > > > > > > > - - - - - Appended by Scientific Atlanta, a Cisco=3D3D20 > > company - - - -=3D3D20 > > >- > > >This e-mail and any attachments may contain information=3D3D20 > > which is confidential, proprietary, privileged or otherwise=3D3D20 > > protected by law. The information is solely intended for the=3D3D20 > > named addressee (or a person responsible for delivering it to=3D3D20 > > the addressee). If you are not the intended recipient of this=3D3D20 > > message, you are not authorized to read, print, retain, copy=3D3D20 > > or disseminate this message or any part of it. If you have=3D3D20 > > received this e-mail in error, please notify the sender=3D3D20 > > immediately by return e-mail and delete it from your computer. > > > > > > > > >------------------------------------------------------------------ > > >To unsubscribe from si-list: > > > si-list-request@xxxxxxxxxxxxx <mailto:si-list-request@xxxxxxxxxxxxx> with 'unsubscribe' in the Subject field > > > > > >or to administer your membership from a web page, go to:=3D3D20 > > > //www.freelists.org/webpage/si-list > > > > > >For help: > > > si-list-request@xxxxxxxxxxxxx <mailto:si-list-request@xxxxxxxxxxxxx> with 'help' in the Subject field > > > > > >List FAQ wiki page is located at: > > > http://si-list.org/wiki/wiki.pl?Si-List_FAQ > > > > > >List technical documents are available at: > > > http://www.si-list.org > > > > > >List archives are viewable at: =3D3D20 > > > //www.freelists.org/archives/si-list > > >or at our remote archives: > > > http://groups.yahoo.com/group/si-list/messages > > >Old (prior to June 6, 2001) list archives are viewable at: > > > http://www.qsl.net/wb6tpu > > > =3D3D20 > > > > > > =3D3D20 > > > > >=3D3D20 > > > - - - - - Appended by Scientific Atlanta, a Cisco company - - - - - >=3D >=3D3D > This e-mail and any attachments may contain information which is =3D >confident=3D3D >ial, proprietary, privileged or otherwise protected by law. The =3D >information=3D3D > is solely intended for the named addressee (or a person responsible for >=3D >de=3D3D >livering it to the addressee). If you are not the intended recipient of >=3D >thi=3D3D >s message, you are not authorized to read, print, retain, copy or =3D >dissemina=3D3D >te this message or any part of it. If you have received this e-mail in = >=3D >erro=3D3D >r, please notify the sender immediately by return e-mail and delete it = >=3D >from=3D3D > your computer. > >------------------------------------------------------------------ >To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx <mailto: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 <//www.freelists.org/webpage/si-list> > >For help: > si-list-request@xxxxxxxxxxxxx <mailto:si-list-request@xxxxxxxxxxxxx> with 'help' in the Subject field > >List FAQ wiki page is located at: > http://si-list.org/wiki/wiki.pl?Si-List_FAQ > >List technical documents are available at: > http://www.si-list.org > >List archives are viewable at: =3D20 > //www.freelists.org/archives/si-list >or at our remote archives: > http://groups.yahoo.com/group/si-list/messages >Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > =3D20 > >------------------------------------------------------------------ >To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx <mailto: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 <//www.freelists.org/webpage/si-list> > >For help: > si-list-request@xxxxxxxxxxxxx <mailto:si-list-request@xxxxxxxxxxxxx> with 'help' in the Subject field > >List FAQ wiki page is located at: > http://si-list.org/wiki/wiki.pl?Si-List_FAQ > >List technical documents are available at: > http://www.si-list.org > >List archives are viewable at: =20 > //www.freelists.org/archives/si-list >or at our remote archives: > http://groups.yahoo.com/group/si-list/messages >Old (prior to June 6, 2001) list archives are viewable at: > http://www.qsl.net/wb6tpu > =20 > >------------------------------------------------------------------ >To unsubscribe from si-list: > si-list-request@xxxxxxxxxxxxx <mailto: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 <//www.freelists.org/webpage/si-list> > >For help: > si-list-request@xxxxxxxxxxxxx <mailto:si-list-request@xxxxxxxxxxxxx> with 'help' in the Subject field > >List FAQ wiki page is located at: > http://si-list.org/wiki/wiki.pl?Si-List_FAQ > >List technical documents are available at: > http://www.si-list.org > >List archives are viewable at: > //www.freelists.org/archives/si-list >or at our remote archives: > http://groups.yahoo.com/group/si-list/messages >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 FAQ wiki page is located at: http://si-list.org/wiki/wiki.pl?Si-List_FAQ List technical documents are available at: http://www.si-list.org List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages 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 FAQ wiki page is located at: http://si-list.org/wiki/wiki.pl?Si-List_FAQ List technical documents are available at: http://www.si-list.org List archives are viewable at: //www.freelists.org/archives/si-list or at our remote archives: http://groups.yahoo.com/group/si-list/messages Old (prior to June 6, 2001) list archives are viewable at: http://www.qsl.net/wb6tpu