```
Anne,

I'd like to jump in with a couple comments.  Dawson and others have
addressed this quite thoroughly, but jitter can be a difficult
subject.  First, regarding your 15% vs 30% question below, I believe
the answer is 30%.  As Dawson and others have stated, the pattern
...1111101... (and it's inverse) induces the worst case, tending to
squeeze the "0" out of existence.  For those interested in the details,
I'll insert a small derivation below.  This single effect induces most
of the DJ.

Second, this effect is not symmetrical.  That is, a 30% width reduction
does not guarantee 15% from the right and 15% from the left edge.
DJ histograms are often decidedly unsymmetrical.

Third, this effect is used to construct worst case patterns.  Low
frequency patterns (e.g., ...0000111100001111...) induce late edges.
High frequency patterns (...01010101...) induce early edges.  Switching
back and forth between the two forces the receiver to alternately
align early, then late, etc., possibly exciting overshoots in its
transient response.  This is the technique used in Fibre Channel's
CJTPAT "jitter tolerance" pattern.

Regards,
Mike Jenkins
LSI Logic

Anne O'Connell wrote:
>
> Dawson,
>
>
> Assume the pk-pk deterministic jitter at the receiver is 30%, i.e +/-
> 15% and assume for this discussion that there is no random jitter. Does
> this mean that a combination of a bad transmitter and data pattern can
> reduce a single bit to 70% - that is, both edges move by 15% towards
> each other. Or that the combination results in a single bit shrinking or
> stretching by 15% only?
>
> We believe that given the transmitter spec and 8B/10B coding scheme
> which ensures a max run length of 5 and DC balance, that the latter
> description above is correct.
>
> compliance testing. However, eye diagrams convey no information about
> jitter frequency, and in particular, what happens from one bit to the
> transmitter are welcome!
>
> Thanks,
>
> Anne
>

The worst case jitter occurs with a single bit following a long
string of opposite-valued bits.  For example, the 8th bit in the
k28.5 character of 8/10 code (0011111010):

******************************                                   *
*                          *
*                    *
:  *                *
:   *             *
------:-----*---------*------- threshold
:     : *      *
:     :   *   * :
:     :      *  :
->:  T1 :<-  ->:T2:<-
:            :
:            :
:<-- 1 UI -->:

The most delayed edge (in this relatively simple model) is delayed
by T1.  The least delayed edge is delayed by T2.  Hence the worst
jitter is

J = T1-T2.

Assuming the transients are exponentials with time constant 'tau'
and assuming the threshold is midway between the up and down levels
(assumed without loss of generality here to be 1 and 0), then

T1 = tau x ln(2)

Also, the second (rising) exponential starts at exp(-1 UI/tau), so
T2 is solved from:
0.5 = exp(-T2/tau) x (1 - exp(-1 UI/tau))

T2 = tau x ln(2) + tau x ln(1 - exp(-1 UI/tau)),

so                J = tau x ln[1/(1 - exp(-1 UI/tau))].

defining a normalized time constant, tau* = tau/(1 UI), and a
normalized jitter, J* = J/(1 UI), then the normalized jitter is:

J* = tau* x ln[1/(1 - exp(-1/tau*))].

Values of normalized jitter are tabulated below for values of
normalized time constant:

tau*            J*

0.1             0.0000045
0.2             0.00135
0.3             0.0109
0.4             0.0343
0.5             0.0727
0.6             0.126
0.7             0.192
0.8             0.270
0.9             0.359
1.0             0.459
1.1             0.567
1.2             0.684
1.3             0.809
1.44            1.0 (the data eye closes completely)

>
> "Kesling, Dawson W" wrote:
> >
> > Anne,
> >
> > >I think it might be also beneficial to define what pk-pk jitter is at
> > >the receiver from one bit to the next, i.e. at high frequencies -
> > >3.125G/2. Does it mean that:
> > >
> > >1. A single received bit can shrink to 0.35UI - 112 ps? (not surely
> > >practical given the transmitter spec?)
> >
> > You are right. This is not possible given the transmitter spec.
> >
> > >or
> > >
> > >2. Over a pair of received bits, one bit can shrink to 67.5% of nominal
> > >bit (216 ps) and the next bit can stretch to 132.5% of a nominal bit
> > >(424ps), giving an overall jitter between the pair of 0.65 UI? Another
> > >way of describing this is a receiver must successfully land a single
> > >occurrence of a 1 as long as 132.5% or as short as 67.5%. This leads to
> > >a definition of pk-pk jitter as
> > >
> > >       (maxBitTime - minBitTime)/nominalBitTime e.g. 132.5-67.5/100 = 65%.
> >
> > Also not possible given the transmitter spec.
> >
> > >An eye diagram builds up an aggregate picture over many thousands of
> > >bits. If in that sample size, one bit stretched and another bit shrunk
> > >by half pk-pk jitter, it would result in an eye opening of 0.35 UI. It
> > >would not necessarily mean however that any bit had shrunk by 0.65 UI.
> >
> > Right. This is the intent of the receive eye.
> >
> > >A jitter mask describing amplitude of jitter versus frequency from 100hz
> > >to 3.125G/2 would be helpful.
> >
> > There is some desire to avoid a full jitter immunity plot verses frequency
> > if possible due to the compliance testing burden. Even a SONET-like immunity
> > plot has a flat tolerance out to the baud rate and doesn't eliminate the
> > 112ps pulse scenario.
> >
> > If the intent is to avoid a misinterpretation of receive eye compliance
> > requirements, then I would prefer to see a statement such as, "The source
> > for receiver compliance testing must comply with the transmit
> > specifications. A linear filter can be used between this source and the
> > receiver for compliance testing purposes." I haven't thought enough about
> > how to word and incorporate this into the standard, but the purpose is to
> > prevent someone from generating a 112ps pulse and expecting the receiver to
> > comply. In effect, it limits random jitter to 0.35UI (plus a little for
> > noise) and budgets the rest to DJ. This is more like the real world
> > situation. Any thoughts?
> >
> > >- Anne
> >
> > -Dawson

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Jenkins               Phone: 408.433.7901            _____
LSI Logic Corp, ms/G715      Fax: 408.433.7461        LSI|LOGIC| (R)
1525 McCarthy Blvd.       mailto:Jenkins@LSIL.com        |     |
Milpitas, CA  95035         http://www.lsilogic.com      |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

```