Prev: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
Next: MSI for BMD design
From: austin on 1 Apr 2010 10:54
Syms,

Peak to peak is peak to peak. You can take as many (or as few) cycles
as you wish, but do not exceed the peak to peak jitter specification.
(p-p says nothing about jitter spectral content)

Of course if you move the clock edges (with respect to a perfect
mythical mathematical reference) over billions of clock cycles, you
can tolerate more than specified, but the specification is the
specification, and as such, it applies to the cycle to cycle can not
exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
p, etc. The p-p bounds any cycle to any cycle.

Austin
From: rickman on 1 Apr 2010 19:13
On Apr 1, 10:54 am, austin <aus...(a)xilinx.com> wrote:
> Syms,
>
> Peak to peak is peak to peak.  You can take as many (or as few) cycles
> as you wish, but do not exceed the peak to peak jitter specification.
> (p-p says nothing about jitter spectral content)
>
> Of course if you move the clock edges (with respect to a perfect
> mythical mathematical reference) over billions of clock cycles, you
> can tolerate more than specified, but the specification is the
> specification, and as such, it applies to the cycle to cycle can not
> exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
> p, etc.  The p-p bounds any cycle to any cycle.
>
> Austin

Hmmm, do I understand what you are saying? If I take you literally,
then the frequency would have to be spot on, right? The accumulated
drift would add up over many cycles and violate any p-p jitter spec if
you state as being "any cycle to any cycle". I guess it depends on
what you are using as a reference. So what is the reference for
measuring jitter over many cycles? Do you assume the nominal rate or
do you use the actual average clock period of the signal?

Rick
From: John_H on 1 Apr 2010 23:15
On Apr 1, 7:13 pm, rickman <gnu...(a)gmail.com> wrote:
> On Apr 1, 10:54 am, austin <aus...(a)xilinx.com> wrote:
>
> > Syms,
>
> > Peak to peak is peak to peak.  You can take as many (or as few) cycles
> > as you wish, but do not exceed the peak to peak jitter specification.
> > (p-p says nothing about jitter spectral content)
>
> > Of course if you move the clock edges (with respect to a perfect
> > mythical mathematical reference) over billions of clock cycles, you
> > can tolerate more than specified, but the specification is the
> > specification, and as such, it applies to the cycle to cycle can not
> > exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
> > p, etc.  The p-p bounds any cycle to any cycle.
>
> > Austin
>
> Hmmm, do I understand what you are saying?  If I take you literally,
> then the frequency would have to be spot on, right?  The accumulated
> drift would add up over many cycles and violate any p-p jitter spec if
> you state as being "any cycle to any cycle".  I guess it depends on
> what you are using as a reference.  So what is the reference for
> measuring jitter over many cycles?  Do you assume the nominal rate or
> do you use the actual average clock period of the signal?
>
> Rick

Bottom line, in my humble opinion: the PLL jitter spec STINKS. The
PLL may be palatable, but the spec isn't. Like comm systems, there's
a high frequency peak-to-peak jitter that should probably apply and a
20dB/decade climb to lower frequencies beyond a specific frequency
point. This corresponds to a maximum phase comparator error when the
loop is trying to follow the significantly jittering signal. "Wander"
is what they call jitter below 10 Hz in some comm systems. We *can't*
be talking about peak-to-peak jitter down to 10 Hz. That's just
ludicrous and points out specifically why this value needs to be more
properly specified.
From: rickman on 2 Apr 2010 13:26
On Apr 1, 11:15 pm, John_H <newsgr...(a)johnhandwork.com> wrote:
> On Apr 1, 7:13 pm, rickman <gnu...(a)gmail.com> wrote:
>
>
>
> > On Apr 1, 10:54 am, austin <aus...(a)xilinx.com> wrote:
>
> > > Syms,
>
> > > Peak to peak is peak to peak.  You can take as many (or as few) cycles
> > > as you wish, but do not exceed the peak to peak jitter specification.
> > > (p-p says nothing about jitter spectral content)
>
> > > Of course if you move the clock edges (with respect to a perfect
> > > mythical mathematical reference) over billions of clock cycles, you
> > > can tolerate more than specified, but the specification is the
> > > specification, and as such, it applies to the cycle to cycle can not
> > > exceed the p-p, and the cycle to the 15th cycle can not exceed the p-
> > > p, etc.  The p-p bounds any cycle to any cycle.
>
> > > Austin
>
> > Hmmm, do I understand what you are saying?  If I take you literally,
> > then the frequency would have to be spot on, right?  The accumulated
> > drift would add up over many cycles and violate any p-p jitter spec if
> > you state as being "any cycle to any cycle".  I guess it depends on
> > what you are using as a reference.  So what is the reference for
> > measuring jitter over many cycles?  Do you assume the nominal rate or
> > do you use the actual average clock period of the signal?
>
> > Rick
>
> Bottom line, in my humble opinion: the PLL jitter spec STINKS.  The
> PLL may be palatable, but the spec isn't.  Like comm systems, there's
> a high frequency peak-to-peak jitter that should probably apply and a
> 20dB/decade climb to lower frequencies beyond a specific frequency
> point.  This corresponds to a maximum phase comparator error when the
> loop is trying to follow the significantly jittering signal.  "Wander"
> is what they call jitter below 10 Hz in some comm systems.  We *can't*
> be talking about peak-to-peak jitter down to 10 Hz.  That's just
> ludicrous and points out specifically why this value needs to be more
> properly specified.

I agree 100%. The spec should relate to how the device works and not
just some interface standard that requires you to operate far away
from the actual testable limits of the device. Is this an issue of
testing the chips to the spec?

Rick
First  |  Prev  | 
Pages: 1 2 3
Prev: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
Next: MSI for BMD design