RE: Random jitter bandwidth and minimum width pulses
Tom and all,
Thanks for looking into this. I also think we are OK. So we can move on to
another pressing issue:
We increased the recieve jitter tolerance requirement in Irvine from 0.65 to
0.70 UI between 1.875 and 20 MHz, and decreased it from 0.65 to 0.60 UI
above 20 MHz. At that time, no one had hard data to justify that our
transmit jitter and receive tolerance numbers were doable in practice,
though some suggested that we were putting an excessive burden on the
receiver. I'd like to hear from people with working silicon - have we struck
the right balance? Now is the time to present data and convince others if
change is needed in the standard.
-Dawson
-----Original Message-----
From: Tom Lindsay [mailto:Tom.Lindsay@xxxxxxxxx]
Sent: Saturday, February 17, 2001 12:11 PM
To: Kesling Dawson W
Cc: anthony.sanders@xxxxxxxxxxxx; Serial PMD reflector (E-mail)
Subject: Re: Random jitter bandwidth and minimum width pulses
Dawson -
I did some quick scratching, and determined that for single jitter events
that
each have a 1e-12 probability of exceeding +/-0.175 UI (peak, or 0.35 UI
pk-pk),
the worst case probability of two adjacent edges closing 0.25 UI is less
than
1e-13. So, I think we are okay. Am I understanding this correctly?
The fact that random jitter is most likely band-limited, as you pointed out
earlier, should provide additional comfort.
This quick scratching did not take into account transition density (there
are
typically at least twice as many bits as transitions) and that cumulative
distribution functions are single-sided. This stuff is generally "in the
noise".
Tom
"Kesling, Dawson W" wrote:
> 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@xxxxxxxxx]
> Sent: Friday, February 16, 2001 11:42 AM
> To: anthony.sanders@xxxxxxxxxxxx
> 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