We have a design that uses a chain of DLLs internally. That is, the output from one DLL is fed to the input of another DLL. I'm not the designer in this case, but I do want to understand the implications of this. Can anybody point me to the right APP notes or search keywords at the Xilinx site for this? A specific question about the Jitter specification; Does the DLL *add* jitter to any input clock, or is the output jitter the max of input and documented output jitter? (This is Virtex-II.) -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
Xilinx: Pitfalls of chaining DLLs
Started by ●February 18, 2005
Reply by ●February 18, 20052005-02-18
"Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...> We have a design that uses a chain of DLLs internally. That is, > the output from one DLL is fed to the input of another DLL. > I'm not the designer in this case, but I do want to understand > the implications of this. Can anybody point me to the right APP > notes or search keywords at the Xilinx site for this? > > A specific question about the Jitter specification; Does the > DLL *add* jitter to any input clock, or is the output jitter theYes it does. Feed it with a crystal clear clock, and you will get somewhere +/- 200ps jitter. Cascading two DLLs is possible and works quite good, at least if your design has some timing margin. if you multiply a 25 MHz clock to 100 MHz and your timing analyzer gives you a minimum period of 9.99ns, you dont have enough timing margin. There is a nice TechXclusive about this very topic from Austin on the Xilinx website.> max of input and documented output jitter? (This is Virtex-II.)Virtex-II is more complicated, since it has the more advanced DCM, which can do more than simple clock doubling. But every setting om M/N causes different jitter characterisics. Regards Falk
Reply by ●February 18, 20052005-02-18
Stephen, The user's guide details the rules for chaining DLL's and DCM's. Generally speaking, a chain of two is allowed. Chains of three are discouraged. A CLK0, 90, 180, 270, may drive a CLKIN of the second DCM (CLKDV, CLK2X, CLKFX of the first stage may have too much jitter for the next stage -- if you check, and it is low jitter, then it is allowed). Austin Stephen Williams wrote:> > We have a design that uses a chain of DLLs internally. That is, > the output from one DLL is fed to the input of another DLL. > I'm not the designer in this case, but I do want to understand > the implications of this. Can anybody point me to the right APP > notes or search keywords at the Xilinx site for this? > > A specific question about the Jitter specification; Does the > DLL *add* jitter to any input clock, or is the output jitter the > max of input and documented output jitter? (This is Virtex-II.)
Reply by ●February 18, 20052005-02-18
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:37ms1nF5et71bU4@individual.net...> > "Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag > news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...< snip >> > A specific question about the Jitter specification; Does the > > DLL *add* jitter to any input clock, or is the output jitter the > > Yes it does. Feed it with a crystal clear clock, and you will getsomewhere> +/- 200ps jitter.<snip> The term "add" might be misinterpreted here. If (using exagerated numbers for illustration) a DLL generates 1 ns jitter and feeds a second DLL capable of tracking the input jitter and "adding" another 1 ns of jitter, the resulting jitter should be 1.414 ns, not 2.0. It's been pointed out on this board before that the DLLs tend to generate nice jitter spectra rather than the "spikey" results one might expect from a DDS. Also pointed out is that the jitter is additive in the sense that RMS signals are added: square, add, sqaure root.
Reply by ●February 18, 20052005-02-18
"John_H" <johnhandwork@mail.com> wrote in message news:07sRd.12$rp4.630@news-west.eli.net...> "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message > news:37ms1nF5et71bU4@individual.net... > > > > "Stephen Williams" <spamtrap@icarus.com> schrieb im Newsbeitrag > > news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com... > < snip > > > > A specific question about the Jitter specification; Does the > > > DLL *add* jitter to any input clock, or is the output jitter the > > > > Yes it does. Feed it with a crystal clear clock, and you will get > somewhere > > +/- 200ps jitter. > <snip> > > The term "add" might be misinterpreted here. If (using exagerated numbers > for illustration) a DLL generates 1 ns jitter and feeds a second DLLcapable> of tracking the input jitter and "adding" another 1 ns of jitter, the > resulting jitter should be 1.414 ns, not 2.0. > > It's been pointed out on this board before that the DLLs tend to generate > nice jitter spectra rather than the "spikey" results one might expect froma> DDS. Also pointed out is that the jitter is additive in the sense thatRMS> signals are added: square, add, sqaure root. > >John, Isn't it true that the peak-to-peak jitter will add linearly? For example, if you have 100ps of peak-to-peak jitter at the input to a DCM, and the DCM adds 200ps of (uncorrelated) jitter (peak-to-peak), then the output jitter of the DCM is 300ps peak-to-peak, correct? Assuming this is true, then from a meeting-timing-point-of-view, one must use the additive peak-to-peak jitter in the timing budgets. Bob
Reply by ●February 18, 20052005-02-18
Stephen, I think Xilinx website and architecture wizard have some sort of DCMs cascading and jitter calculation approximation. However, you must take into account that using CLKFX output of one DCM as CLKIN of another will create problems. I have used very stable oscillator and i had something like +/- 150 ppm jitter at the output. I have been able to cascade 4 DCMs in one chain, but the resulting clock was purely for internal usage, without going out of FPGA. What is the application? Is the resulting clock very high or not? Sincerely, Vladislav Muravin Senior FPGA Design Engineer Advantech AMT (Advanced Microwave Technologies) 657 Orly Avenue Dorval H9P 1G1 Quebec, Canada Tel: (514) 420-0045 ext. 240 Fax: (514) 420-0073 http://www.advantechamt.com "Stephen Williams" <spamtrap@icarus.com> wrote in message news:3f9d6$421623b1$40695902$20327@msgid.meganewsservers.com...> > We have a design that uses a chain of DLLs internally. That is, > the output from one DLL is fed to the input of another DLL. > I'm not the designer in this case, but I do want to understand > the implications of this. Can anybody point me to the right APP > notes or search keywords at the Xilinx site for this? > > A specific question about the Jitter specification; Does the > DLL *add* jitter to any input clock, or is the output jitter the > max of input and documented output jitter? (This is Virtex-II.) > -- > Steve Williams "The woods are lovely, dark and deep. > steve at icarus.com But I have promises to keep, > http://www.icarus.com and lines to code before I sleep, > http://www.picturel.com And lines to code before I sleep."
Reply by ●February 18, 20052005-02-18
Vladislav Muravin wrote:> Stephen, > > I think Xilinx website and architecture wizard have some sort of DCMs > cascading and jitter calculation approximation. > However, you must take into account that using CLKFX output of one DCM as > CLKIN of another will create problems.Unfortunately, our engineer did exactly that: a DCM (used to be a chain of DCMs) multiplies a PCI 33MHz clock up to 100MHz and sends it off the chip. The return 100MHz clock is connected to another DCM which is used as an internal 100MHz clock phased with the SDRAMS. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
Reply by ●February 18, 20052005-02-18
"Bob" <nimby1_notspamm_@earthlink.net> wrote in message news:35tRd.2922$x53.1388@newsread3.news.atl.earthlink.net...> > "John_H" <johnhandwork@mail.com> wrote in message > news:07sRd.12$rp4.630@news-west.eli.net...<snip>> > It's been pointed out on this board before that the DLLs tend togenerate> > nice jitter spectra rather than the "spikey" results one might expectfrom a> > DDS. Also pointed out is that the jitter is additive in the sense thatRMS> > signals are added: square, add, sqaure root. > > John, > > Isn't it true that the peak-to-peak jitter will add linearly? For example, > if you have 100ps of peak-to-peak jitter at the input to a DCM, and theDCM> adds 200ps of (uncorrelated) jitter (peak-to-peak), then the output jitter > of the DCM is 300ps peak-to-peak, correct? > > Assuming this is true, then from a meeting-timing-point-of-view, one must > use the additive peak-to-peak jitter in the timing budgets. > > BobIt's not true that peak-to-peak jitter values add linearly for guassian distributed phase noise. If you have two sinusoidal jitter modulations (the "spikey" jitter spectra I referred to above) with unrelated frequencies, those will add linearly. Gaussian jitter is a statistical number. If the peak-to-peak is specified at 6-sigma (which it often is) the probability is 0.00034% that either jitter value is at its peak. The probability that *both* values are at their peaks is below 0.000000000012% which is way beyond a 6-sigma spec for the additive values. Square, add, square-root. It's power, not voltage.
Reply by ●February 18, 20052005-02-18
"John_H" <johnhandwork@mail.com> wrote in message news:uyvRd.13$rp4.632@news-west.eli.net...> "Bob" <nimby1_notspamm_@earthlink.net> wrote in message > news:35tRd.2922$x53.1388@newsread3.news.atl.earthlink.net... > > > > "John_H" <johnhandwork@mail.com> wrote in message > > news:07sRd.12$rp4.630@news-west.eli.net... > <snip> > > > It's been pointed out on this board before that the DLLs tend to > generate > > > nice jitter spectra rather than the "spikey" results one might expect > from a > > > DDS. Also pointed out is that the jitter is additive in the sensethat> RMS > > > signals are added: square, add, sqaure root. > > > > John, > > > > Isn't it true that the peak-to-peak jitter will add linearly? Forexample,> > if you have 100ps of peak-to-peak jitter at the input to a DCM, and the > DCM > > adds 200ps of (uncorrelated) jitter (peak-to-peak), then the outputjitter> > of the DCM is 300ps peak-to-peak, correct? > > > > Assuming this is true, then from a meeting-timing-point-of-view, onemust> > use the additive peak-to-peak jitter in the timing budgets. > > > > Bob > > It's not true that peak-to-peak jitter values add linearly for guassian > distributed phase noise. > If you have two sinusoidal jitter modulations (the "spikey" jitter spectraI> referred to above) with unrelated frequencies, those will add linearly. > > Gaussian jitter is a statistical number. If the peak-to-peak is specified > at 6-sigma (which it often is) the probability is 0.00034% that either > jitter value is at its peak. The probability that *both* values are at > their peaks is below 0.000000000012% which is way beyond a 6-sigma specfor> the additive values. Square, add, square-root. It's power, not voltage. > >Yeah, I guess it's just a matter-of-degree as to how you treat it. It depends on how long between logic errors is acceptable. If probability strikes then you're not going to meet timing -- even if it's once in a blue moon. I hear that in V7 of the Xilinx software, they will be changing they way that jitter sources' effects are combined. From what I've heard, V6 adds them rms'ish. V7 will not, but I don't have the details. We think we're getting screwed by the way that V6 is treating this matter. We're having to over-specify our jitter in order to stop the runtime errors we're seeing. However, to be fair, the way that they add jitter in V6 may not be the only source of our problem (but we think it's part of it). Bob
Reply by ●February 22, 20052005-02-22
John_H wrote:> Gaussian jitter is a statistical number. If the peak-to-peak is specified > at 6-sigma (which it often is) the probability is 0.00034% that either > jitter value is at its peak. The probability that *both* values are at > their peaks is below 0.000000000012%Hmm. That's every five minutes for a 400MHz clock? So if I use this for my timing budget the chip might fail every five minutes? Kolja Sulimma
