Spartan 6 PLL - Why such a strict input jitter requirement?

Hi there,
Looking for insight here - Spartan 6 adds a PLL to the mix and we
wondered to what extent it can be used to filter jitter, for example
for a Synchronous Ethernet product requirement we have. However, the
SP6 PLL seems to have a very stringent max input jitter requirement.
It does not allow an input clock with more that 1ns jitter (not much).

Looking in the datasheet, the SP6 PLL looks like a classic PLL, so why
the input jitter requirement? (I can understand the jitter requriement
for a DCM).

I.e.
Table 49, pg 45 of DC and switching characteristics.
FINJITTER Maximum Input Clock Period Jitter All <20% of clock input
period or 1 ns Max

Anyone (from Xilinx?) prepared to comment on this?

Cheers
Andrew

Andrew,

1ns is a LOT of jitter (in my book, that is).  20% of the clock period
is also a lot of jitter (to me).

Depends on what you define as "a lot."

Austin

On 3/30/2010 6:56 PM, austin wrote:
> Andrew,
>
> 1ns is a LOT of jitter (in my book, that is).  20% of the clock period
> is also a lot of jitter (to me).
>
> Depends on what you define as "a lot."
>
> Austin
>
Whether it is a lot or not depends on the frequency of the jitter. What 
are we talking about here? Cycle-cycle jitter?

Syms.

Good Question!

I am presuming it is peak to peak jitter, but I may be incorrect...

I will go ask.

Austin

Peak to peak,

Austin

On Mar 30, 1:56=A0pm, austin <aus...@xilinx.com> wrote:
> Andrew,
>
> 1ns is a LOT of jitter (in my book, that is). =A020% of the clock period
> is also a lot of jitter (to me).
>
> Depends on what you define as "a lot."
>
> Austin

In my communications days, 1ns of peak-to-peak jitter is tiny.  That
would almost qualify as jitter-free by some accounts.  Didn't you come
from that background, Austin?

If a PLL is used for jitter cleanup, the 0.15UI or 0.20UI levels for
the high frequency end of the jitter tolerance are common with lower
frequency values that start up a 20dB/decade slope as the frequency
goes lower corresponding to a required limit on the filter pole in the
PLL loop filter.  If you start using rates at 155Mb/s and below, 1ns
peak-to-peak jitter is the proverbial drop in the bucket.

The whole reason PLLs were so good at jitter cleanup is that the phase
comparator runs at a remarkably lower frequency allowing offsets
significantly greater than several unit intervals.  While silicon PLLs
are higher in frequency with higher phase comparator frequencies, they
shouldn't be *that* much higher.

On Mar 31, 10:42=A0am, John_H <newsgr...@johnhandwork.com> wrote:
>
> The whole reason PLLs were so good at jitter cleanup is that the phase
> comparator runs at a remarkably lower frequency allowing offsets
> significantly greater than several unit intervals. =A0While silicon PLLs
> are higher in frequency with higher phase comparator frequencies, they
> shouldn't be *that* much higher.

are you assuming a 'classic PLL' design ? - it is unlikely the FPGA
PLLs are classic in nature, but are more likely to have 'other tricks'
and shortcuts to integrate better in digital process.

-jg

On 3/30/2010 9:41 PM, austin wrote:
> Peak to peak,
>
> Austin

Hi Austin,

Right, but is that from one cycle to the next? Or from one cycle to 
infinity? Or beyond?

My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely 
gold colour!) gives me a signal, which it is claimed has 50ns of jitter. 
That's all the spec. I get. One pulse per second comes out of this 
bugger. Should I worry? Is 50ns "a lot"?

Syms!

On Mar 30, 7:24=A0pm, Symon <symon_bre...@hotmail.com> wrote:
> Right, but is that from one cycle to the next? Or from one cycle to
> infinity? Or beyond?
>
> My Trimble GPS box (it's a nice brushed aluminium can, anodised a lovely
> gold colour!) gives me a signal, which it is claimed has 50ns of jitter.
> That's all the spec. I get. One pulse per second comes out of this
> bugger. Should I worry? Is 50ns "a lot"?

Heh.

Reminds me of a few years ago, when I was pressed into service to
torture (I believe "verify" is the correct word, but whenever someone
wants me to test something, they're kidding themselves if they think
I'm anything other than a pit bull.  Maybe that's why they usually
just have me writing high level system specs and designing emulation
platforms.  But I digress...) a USB 2.0 high speed receiver.

I thought the USB definition of jitter for high speed was crystal
clear -- just stack up 480 bit times worth of data vertically and see
if the template was ever violated.  But, it turns out that a designer
dedicated to proving himself "right" can find something to disagree
about even there.  He decided that (since my test case that really put
his design into a tailspin was not running at exactly the nominal 480
Mb/s) the 480 bit times you were stacking had to be at exactly 480 Mb/
s, and not at the nominal transmit frequency.  This let him "prove"
that I was exceeding the jitter tolerance, by adding drift and jitter
together to show that the signal was outside the specified template!

I showed him (well, tried to show him) that, if you used his wacky
definition, then if you took a signal that was transmitted at the edge
of the specified frequency margin, and stacked up 480 of those bit
times using nominal rather than transmitted period, you would violate
the template EVEN WITH ZERO JITTER, so that couldn't be what they
mean, right?  I never convinced him of that, but the management
understood.

I also never convinced him that when his uber-fancy data recovery lost
lock and just started spewing garbage (which it did in a rather
spectacular way when it got lost, not just losing a bit here or
there), that a 16 bit CRC was mathematically reduced to the same
efficacy as a 16 bit checksum, e.g. incorrectly passing good data on 1
out of every 65536 bad packets.

Regards,
Pat

On Mar 30, 7:58=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> are you assuming a 'classic PLL' design ? - it is unlikely the FPGA
> PLLs are classic in nature, but are more likely to have 'other tricks'
> and shortcuts to integrate better in digital process.
>
> -jg

There are silicon VCOs with on-board PLLs that do a fine job with
rather standard - albiet higher frequency - phase detector schemes.
We may not have the charge pumps with two caps and a resistor but the
schemes are still somewhat standard.  Maybe it's done very different
in the FPGA realm.