RE: XAUI receiver characteristics
Hi,
If jitter tolerance is specified to be 0.65UI then it will be interpreted as
you can have a data bit as short as 112ps(surely not practical) regardless
of how the transmit jitter is specified. The shortest bit pulse will come
when you have a consecutive run of five 1's followed by a single zero or
vice versa, and this condition is frequently present in any real world data
stream. Therefore, it should be considered how small this pulse can get and
still practically be recovered by the receive side. The jitter tolerance
spec should be based on this practical limitation. If the transmit jitter
spec is changed, say to 0.30UI, then it should come from the jitter
tolerance budget and make it 0.6UI.
Also it seems more convenient to have separate numbers for DJ and RJ, where
DJ is specified in UI and RJ is specified as RMS value in picoseconds.
If specification of the jitter versus frequency mask is avoided, then it
will be benefecial to specify a test pattern for jitter tolerance compliance
testing. This is because the jitter frequency depends upon the test pattern
used.
Thank you,
Kulwant Brar
Conexant Systems, Inc.
-----Original Message-----
From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
Sent: Tuesday, October 17, 2000 5:52 PM
To: HSSG
Subject: RE: XAUI receiver characteristics
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