RE: [802.3ae] XAUI Rj TR comment
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