Prev: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
Next: MSI for BMD design
From: John_H on 30 Mar 2010 18:42
On Mar 30, 1:56 pm, austin <aus...(a)xilinx.com> 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

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.
From: -jg on 30 Mar 2010 19:58
On Mar 31, 10:42 am, John_H <newsgr...(a)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.  While 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
From: John_H on 30 Mar 2010 21:17
On Mar 30, 7:58 pm, -jg <jim.granvi...(a)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.
From: whygee on 31 Mar 2010 03:42
Patrick Maupin wrote:
> 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.

It is easily proved, sure, and CRC are not magic.
"Garbage in, garbage out", so if you input
random data, CRC fails in average every 2^N packet,
where N is the size of your CRC (in bits).
That's probably why the Ethernet protocols use 32 bits...

wait, did I just imply that 100BaseT is better than USB ??

> Regards,
> Pat
yg

--
http://ygdes.com / http://yasep.org
From: Muzaffer Kal on 31 Mar 2010 11:04
On Wed, 31 Mar 2010 09:42:30 +0200, whygee <yg(a)yg.yg> wrote:

>Patrick Maupin wrote:
>> 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.
>
>It is easily proved, sure, and CRC are not magic.
>"Garbage in, garbage out", so if you input
>random data, CRC fails in average every 2^N packet,
>where N is the size of your CRC (in bits).
>That's probably why the Ethernet protocols use 32 bits...
>
>wait, did I just imply that 100BaseT is better than USB ??
>

As opposed to USB, there is no CRC at the PHY level in 100B-TX (nor in
1000B-TX; which has FEC but still no CRC). The 32 bit CRC is at MAC
layer and is more or less independent of the PHY.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Spartan 3E: MAX_STEPS as a function of CLKIN frequency
Next: MSI for BMD design