Re: XAUI receiver characteristics
Hi Anne
I have seen lots of traffic on the jitter issue. The XAUI jitter
specification
was derived based on the FC Jitter Methodology (WWW.t11.org) and
originally came
from SONET. I believe lots of the discussion here would be answered if
you are
willing to read some FC Jitter Methodology spec. which is some 100
pages.
I am going to briefly describe the methodology Below
Total jitter = DJ + 1Sigma (Random Jitter)
Deterministic Jittere has several component: ISI, reflection, Periodic
Jitter,
and Sinusoidal Jitter.
In addition we need to specify the corner frequency for the PLL, based
on
FC and SONET the corner frequency would 3125/1667 = 1.875 MHz. Having
the
corner frequency actually reduces the jitter burden as it would scale
low frequency jitter. In addition you need to test the receiver for
jitter
tolerance.
Eye diagram does shows basic behavior of the signal, but it can't
guarantee BER 1E-12 compliance. Eye diagram is a good tool to view and
give you
an accurate measurement of your high frequency jitter such as ISI, but
it will
underestimates random jitter. Other method such as BERT, TIA, or
golden PLL can be used to measure more accurately. These technique
already take in to account bit movement and shrinkage. I do agree
none of the above methods are trivial for working link.
Good Luck
Ali Ghiasi
Newport Comunnication/Broadcom
Anne O'Connell wrote:
>
> 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