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

RE: [802.3ae] XAUI Rj TR comment




I agree with Mike,

From our experiments and simulations, jitter power spectral content above
the Nyquest rate of the data signal alias down below the Nyquest rate in a
digital system.

Regards,

Dennis

-----Original Message-----
From: Mike Jenkins [mailto:jenkins@xxxxxxxx]
Sent: Tuesday, July 31, 2001 6:25 PM
To: Howard A. Baumer
Cc: Lindsay, Tom; HSSG_reflector (E-mail)
Subject: Re: [802.3ae] XAUI Rj TR comment


Howard, Tom,

A comment on bandlimiting the RJ:  Since jitter is a discrete, sampled 
quantity, I believe it is necessarily band limited to half the Nyquist 
rate, that is, half the bit rate.  I don't believe the spec needs to 
state this, but I don't think it would hurt to add such a statement, 
either.

Regards,
Mike

"Howard A. Baumer" wrote:
> 
> Tom,
> 
> - Bandlimited RJ is likely, but I have not found it as part of the
> spec.  I don't think I've missed this have I?  This is the point we're
> trying to make. In fact, we would like a bandlimitation on the RJ, it
> would solve a lot of problems.
> 
> - The limiter idea will only work if the RJ is bandlimited to less than
> the bit rate. With a 20dB/dec roll off, the cut-off should probably be
> well lower than that to make it work reliably, probably less than half
> the bit rate.
> 
> - If you see a random spectrum at baseband, that means that the additive
> RJ is "leaking" through. You already run the risk of having false clock
> edges with a probability higher than 10e-12.
> 
> - Whether or not receive side equalization boost the high frequencies is
> determined by its implementation.
> 
> - We're still confused on how you would ever get 0.55UI of RJ. If
> crosstalk adds so much jitter, then your vertical eye (SNR) is closing
> very rapidly too. And if you have a TX VCO / PLL that creates that much
> jitter, then your RX clk will not be very good either and the system
> will not work.  Basically, you can build a TX with preemphasis (no DJ)
> and 0.55UI of RJ and your TX will still meet the far end spec. If a RX
> system is then built with equalization, and you test it with max DJ
> (0.37) and minimum RJ (0.18) and it passes, it then meets spec. But if
> your RX uses the same clk as the TX, the system will not work. Question:
> Do you call this RX compliant or not?
> 
> - We indicate the RJ rms addition with the "+rms" symbol. Since we
> assumed the RJs are not correlated we had to rms add them.
> 
> - The whole point of including the RX jitter, is to make this part of
> the complete system calculation. You have to include the whole system
> (TX, Media and RX) to know when the system fails and it is at this
> complete system failure point that the individual budgets can be
> determined. To do the calculations correctly, you need to take a look at
> the combined probabilities, not the separate individual probabilities.
> In these system calculations we just evenly divided the RJ between the
> transmitter and the receiver.
> 
> - Yes the receiver has 0.35UI of budget of which we alocated 0.1UI to DJ
> (internal bandwidth limitations, matching, etc..) and the rest to RJ
> (0.25).  The conclusions came up with 6.2ps rms RJ for the RX which is
> in line.
> 
> Howard Baumer
> 
> "Lindsay, Tom" wrote:
> >
> > Howard -
> >
> > I am in line with Mike's comments.
> >
> > I have successfully added RJ into the input clock. The clock was
> > sinusoidal, which gave it a nice slope, and the RJ was bandlimited to
> > approx the serial bit rate. I ran into clock input error problems at
> > high levels of RJ, but I was able to get above the magnitude I needed.
> >
> > This is not to say it was easy.
> > 1. The clock input may have bandlimiting - my pattern generator appeared
> > to be "wide-open".
> > 2. The presumption is that the clock input limits. I had to include an
> > amplified input, because without it, I saw the random spectrum at
> > baseband and not only around the data. Don't ask me why...
> >
> > Somewhere I heard a reason for limiting RJ was to provide control for
> > equalizing receivers, so that they wouldn't boost high frequency RJ. Is
> > that true? If so, rather than limiting RJ magnitude, I would rather put
> > some limits on RJ frequency.
> >
> > Other than that, I apologize for getting lost around page 14 of your
> > presentation.
> > 1. Are you adding RJ sources linearly or root-sum-square? Are you
> > assuming they are correlated?
> > 2. How/why are you analyzing the effects of RX jitter contribution? From
> > the existing budget, it seems that the Rx has 0.35 of budget left with
> > varying amounts of RJ and DJ it can contribute depending on the input
> > balance. I am probably missing something, this should be a lot more
> > straightforward than it appears to be. Can you explain?
> >
> > Thanks, Tom Lindsay
> > Stratos
> > 425/672-8005
> >
> > -----Original Message-----
> > From: Mike Jenkins [mailto:jenkins@xxxxxxxx]
> > Sent: Monday, July 30, 2001 1:54 PM
> > To: HSSG_reflector (E-mail)
> > Subject: Re: [802.3ae] XAUI Rj TR comment
> >
> > Howard,
> >
> > Your presentation is a very nice summary, particularly of the issues
> > regarding jitter tolerance.  Thanks.
> >
> > If you don't mind, I would like to make a comment and ask a question:
> >
> >  * With regard to your method #2 for RJ testing ("adding noise to
> >    clock"), I suspect that very reasonable bandwidth limitations
> >    on the Gaussian noise would avoid any unintended zero crossings.
> >    The available bit rate clocks seem to have more than adequate
> >    amplitude control and spectral purity to make this amplitude-to-
> >    phase conversion very reliable and repeatable.
> >
> >  * This is more of a question.  My background is with the Fibre
> >    Channel jitter working group which evolved this methodology.
> >    The implicit assumption behind allowing RJ =< TJmax - DJ(actual)
> >    was that the worst case was DJ=DJmax.  Random jitter was assumed
> >    to be more benign than DJ.  Hence, testing is required only for
> >    DJ=DJmax.  I would appreciate hearing any argument to rebut that
> >    assumption.
> >
> > Regards,
> > Mike Jenkins
> >
> > "Howard A. Baumer" wrote:
> > >
> > > To all concerned,
> > >      I put in a TR Comment against D3.1 stating the desire to put a
> > > maximum
> > > limit on the TX Rj.  This comment was rejected and left unresolved.
> > > There was fairly wide agreement that having a max limit on TX Rj
> > should
> > > be done but that we should first get a broader input on what this
> > limit
> > > should be.  I took on the action item to start a reflector discussion
> > to
> > > determine this limit.
> > >      The current draft sets a limit for Tj and a limit for Dj and then
> > > defines Rj aa Rj = Tj(max) - Dj(actual).  The TR comment proposes that
> > a
> > > limit be set for Tj, Rj and Dj and that Rj(actual) + Dj(actual) <
> > > Tj(max). There is a presentation that we are developing that
> > > attempts to figure out a limit for Rj.  It can be found at
> > > http://www.ieee802.org/3/ae/public/documents/XAUIjittercomments.pdf.
> > > Please review and comment.
> > >      This presentation also brings out a problem with the current
> > Jitter
> > > Tolerance test technique.
> > >
> > > Howard Baumer
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >  Mike Jenkins               Phone: 408.433.7901            _____
> >  LSI Logic Corp, ms/G715      Fax: 408.433.7495        LSI|LOGIC| (R)
> >  1525 McCarthy Blvd.       mailto:Jenkins@xxxxxxxx        |     |
> >  Milpitas, CA  95035         http://www.lsilogic.com      |_____|
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Mike Jenkins               Phone: 408.433.7901            _____     
 LSI Logic Corp, ms/G715      Fax: 408.433.7495        LSI|LOGIC| (R)
 1525 McCarthy Blvd.       mailto:Jenkins@xxxxxxxx        |     |     
 Milpitas, CA  95035         http://www.lsilogic.com      |_____|    
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pc