Xilinx: Pitfalls of chaining DLLs

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,
 Click to see the full signature
Reply to
Stephen Williams
Loading thread data ...

"Stephen Williams" schrieb im Newsbeitrag news:3f9d6$421623b1$40695902$ snipped-for-privacy@msgid.meganewsservers.com...

Yes 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.

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 to
Falk Brunner

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).

Aust>

Reply to
Austin Lesea

< snip >

somewhere

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 to
John_H

capable

a

RMS

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 to
Bob

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
formatting link

Reply to
Vladislav Muravin

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,
 Click to see the full signature
Reply to
Stephen Williams

generate

from a

RMS

DCM

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 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 to
John_H

that

example,

jitter

must

I

for

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 to
Bob

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

Reply to
Kolja Sulimma

Another thing to watch out for in certain cascaded and external DCM constructs, where absolute delay from input_dcm_1 to output_dcm_2 is important, is the intentionally early ( ~1.5ns in V2 ) DCM output clock arrival time when using the default SYSTEM_SYNCHRONOUS mode of the DCM.

DCM in->out delays were modeled oddly in older versions of the SW, but I haven't checked how 6.3 handles it- see the Answer Records listed at the bottom of this old post:

formatting link
Brian

Reply to
Brian Davis

Kolja,

Exactly. Often folks do not realize that 12, or even 14 sigma is required if you wish to be 'error free'.

The great news is that the difference between real jitter in physical systems, and a theoretical gaussian distribution is that in the real world, we do not have infinite energy.

Real world systems begin to have real physical limits that prevent you from having to worry about 14 sigma cases.

But, you should worry out to 12 sigma (or be able to tolerate occasional errors).

Often you hear people say that "jitter is unbounded" which is not exactly true. What is true is that the longer you measure, the more jitter you get - up to a point (the peak to peak grows increasingly slowly as the number of samples increases, so at some point, it isn't worth the time to wait, as you will only get 10 more ps p-p by waiting another day!).

"Tail fitting" fits the tails of a gaussian curve (right and left) to the measured histogram, which is useful for not waiting around forever, and getting your 12 to 14 sigma results. Or you can add another 10% after 2 million samples, and be very very close to the "right" answer (and a little conservative).

We only measure jitter in this way (tail fitting), because all other methods have the problem that you detailed in your posting: don't you have to sample (wait) longer to know the 'truth'?

The other point is that in digital systems, it is not the positive excursion (the lowest or longest period) that gets you in trouble, it is the shortes (or fastest).

Take the peak to peak jitter, divide it by two, and take that away from the clock period to find your worst case min clock period. That is the constraint you need to have slack for, not the clock period itself.

formatting link

Austin

Kolja Sulimma wrote:

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.