RE: XAUI receiver characteristics
I expect that in the absense of relections, the minimum width is when the
signal has been low (or high) for 5 bit times (BT) and then goes high (or
low) for a single bit. If this is right, then the eye opening is defined by
such single bits and the minimum width is 70% in your example. Reflections
and noise will cause the opening to be slightly smaller than the single bit
width, but I don't expect by much since the line loss is high and the pair
is differential. I'm only using my common sense and must be overlooking
something if you came to a different conclusion. Can someone else help?
Concerning jitter and the eye mask, it is true that the mask does not
contain information about jitter frequency. But I don't think jitter
frequency is the real issue, is it? If the CDR is immune to the required
pk-pk jitter at low frequencies, then it is also immune at high frequencies.
Isn't receiver front end bandwidth the real issue? This should not be
specified in the standard as it is an implementation design choice. The
standard should only take reasonable care to avoid implying an impractical
compliance requirement (such as a 112ps rectangular pulse!).
From: Anne O'Connell [mailto:anne.oconnell@xxxxxxxxxxx]
Sent: Wednesday, October 18, 2000 7:44 AM
To: Kesling, Dawson W
Cc: HSSG; con cremin
Subject: Re: XAUI receiver characteristics
Thank you for your reply. A few additional comments - I would appreciate
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.
I agree with your comments about the jitter masks - it makes for easier
compliance testing. However, eye diagrams convey no information about
jitter frequency, and in particular, what happens from one bit to the
next. But your comments re the receiver being tested with a compliant
transmitter are welcome!
"Kesling, Dawson W" wrote:
> >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.
> >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 =
> 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
> 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
> 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