Re: [802.3ae] XAUI Rj TR comment
Replying to Mike's comment:
It depends on the definition of jitter. If jitter is considered at the
zero crossings and/or on the peaks *only*, it is effectively a sampled
system and the frequency
spectrum of the jitter will alias. But when the data signal is viewed
as continuous time this
is not true. (Usually this is called phase noise though; not "jitter").
As far as I know, the IEEE spec does not prescribe to view the data
signal as a sampled signal(?), nor does it prescribe the sample
frequency with which you need to look at the data signal. So the
frequency at which the RJ will alias (if at all) is not a given.
So I agree with Tom.
Howard Baumer
"Lindsay, Tom" wrote:
>
> Folks - I don't think the Nyquist theory applies here. Once sampled, I
> agree that it does, but Howard's point is ahead of sampling. He is
> considering a real-time waveform, that with noise, results in irregular
> sampling. That is, noise could cause additional and erroneous samples to
> occur.
>
> Tom
>
> -----Original Message-----
> From: Dennis Petrich [mailto:dpetrich@xxxxxxxxxxxxx]
> Sent: Wednesday, August 01, 2001 6:15 AM
> To: 'jenkins@xxxxxxxx'; Howard A. Baumer
> Cc: Lindsay, Tom; HSSG_reflector (E-mail)
> Subject: 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