RE: Random jitter bandwidth and minimum width pulses
Tom,
Thanks for your thoughts. Here are some answers to your questions.
1. I've tried various seeds and come up with similar results.
2. The probability of minimum width pulses is about 1e-4, as you reasoned.
But pulses short than 0.75 UI still don't get through the compliance channel
without violating the receive eye (my sim results). The amount of jitter
required to cause pulses of this width is not so far out on the Gaussian
tail and the probability goes up fast. That being said, I don't think it is
a real concern since real systems don't have so much RJ as I'm sim'ing with.
(I've increased RJ to get about 1e-2 BER instead of 1e-12.)
3. My data sequence is alternating K28.5. So there are 500 jittered edges in
1000 baud.
4. I chose 20 MHz as a rough PLL corner and was thinking like you that it
was reasonable. I better let you experts debate it and let me know!
-Dawson
-----Original Message-----
From: Tom Lindsay [mailto:Tom.Lindsay@Vixel.com]
Sent: Friday, February 16, 2001 11:42 AM
To: anthony.sanders@infineon.com
Cc: Kesling Dawson W; Serial PMD reflector (E-mail)
Subject: Re: Random jitter bandwidth and minimum width pulses
Dawson -
I don't see anything fundamentally wrong with your methods. I would be
curious if you get the same result with a different random seed - that is,
were you just statistically unlucky? I would expect the probability of the
pulse width being reduced by 100ps (each edge shifted close to 56ps, the
peak value at 1e-2) would be approx the square of 1e-2 (1e-4), at least
easily less than 1e-3.
Not relevant to your issue, but what is the data sequence?
Run time is 1000 baud (bits?), but how many transitions (jitter events) are
there? If 8B10B, I would guess between 500 and 600?
Anthony - rather than 100ps, don't you mean 56ps (half of 112 - I am
assuming you are referring to the jitter distrbution, not cycle to cycle)?
Regarding PLL filtered jitter spectra, I have looked at a ton of spectra
over the last few years, and every case is substantially reduced at higher
frequencies. There may be a floor, but usually so far down that it doesn't
contribute much to total RJ. So, I think the 20 MHz -3dB value is quite
reasonable, not extreme at all. Maybe it depends on what mechanisms we want
to include under RJ - crosstalk is usually uncorrelated, but not Gaussian,
and FC has thrown it into the DJ category. If we stick with thermal and shot
noises, then I think filtering is easily justifiable.
Looks like you're having fun!
Tom Lindsay
Vixel
Anthony Sanders wrote:
> Dawson,
>
> You are correct, the occurance of RJ giving an amplitude greater that
> the 100ps should then be the BER, but to expect a minimum pulse width to
> also occur is a little unexpected. You generated this gaussian in matlab
> so I understood, by using a transfer function from the random number
> generated; perhaps you would like me to take a look at it. IŽll dig out
> my Gaussian function and send it to you in return.
>
> I certainly do not think that we should be introducing a filter on to
> this jitter as the assumption is that this RJ is white. In reality of
> course it is a more a PLL filtered, 1/f3, 1/f2 and 1/f noise with a
> superimposed white noise, but I donŽt think we should get into this yet.
>
> Anthony.
>
> "Kesling, Dawson W" wrote:
> >
> > Jeff and Anthony (and other interested parties),
> >
> > I see several minimum width pulses without the jitter filter in place in
my
> > sim. This is surprising to me. Here's a description and some plot. Any
> > ideas?
> >
> > The "jit_raw" file that is attaches shows (from left to right and top to
> > bottom) the jitter applied at each edge in sequence (measured with
respect
> > to the ideal edge position), the difference between jitter at each edge
and
> > the jitter at the previous edge (cycle-to-cycle jitter), the amplitude
> > spectrum of the jitter, and the probability distribution (histogram) of
the
> > jitter. The RMS jitter is 24 ps, chosen to get 1e-2 BER with 0.35UI
pk-pk
> > (=112 ps p-p) Gaussian RJ. The run time is 1000 baud, so I'd expect
about 10
> > traces to cross the eye. As you can see from the plot, there are also
about
> > 10 occurances where cycle-to-cycle jitter is about -100 ps. These
occurances
> > cause minimum-width pulses due to successive edges being shifted toward
each
> > other severely. I'm surprised the frequency of occurance of minimum
width
> > pulses is as large as the BER! These will definitely result in receive
eye
> > violations after going through the channel. If this is real, it suggests
> > that our compliance system is not self consistent. One alternative is
that
> > real transmit jitter is not so large and/or is bandlimited below half
the
> > baud rate. Anthony, you mentioned that you are using band-limited jitter
so
> > you might not see this effect if you limit well below 1.56 GHz. What
> > bandwidth and rolloff are you using? Any idea why Mysticom doesn't see
this
> > either?
> >
> > The "jit_20M" file shows the same jitter sequence after being filtered
> > through a single pole discrete time low pass at 20 MHz. (This filter is
> > applied to the sequence of jitter values, not to the jittered waveform.)
The
> > filtering is apparent in the amplitude spectrum. The RMS of the
pre-filtered
> > jitter was increased according to a derived formula to get the same
> > post-filter RMS jitter as the unfiltered case. In spite of the fact that
the
> > resulting RMS jitter is clearly larger than theorectically anticipated,
he
> > maximum cycle-to-cycle jitter is still reduced drastically. It stays
below
> > about 20 ps, so no minimum-width pulses are generated. This filtering
may be
> > extreme, but demonstrates the method I'm using to avoid minimum width
> > pulses.
> >
> > all thoughts are appreciated.
> > -Dawson
> >
> > <<Jit_20M.ZIP>> <<Jit_raw.ZIP>>
> >
> >
------------------------------------------------------------------------
> > Name: Jit_20M.ZIP
> > Jit_20M.ZIP Type: Zip Compressed Data
(application/x-zip-compressed)
> > Encoding: base64
> >
> > Name: Jit_raw.ZIP
> > Jit_raw.ZIP Type: Zip Compressed Data
(application/x-zip-compressed)
> > Encoding: base64