Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: XAUI receiver characteristics




Dawson,

Thank you for your reply. A few additional comments - I would appreciate
your feedback. 

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!

Thanks,

Anne 
 

"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