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