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