RE: [802.3ae] XAUI Rj TR comment
In other words and regardless of definitions, there is no clean clock
that comes along and does the sampling here at this point in the
equipment setup. Rather, this is the signal that defines the clock as it
goes up and down across a threshold. Noises can cause additional
transitions across the threshold, and each transition effectively causes
a sample. As I said before, noise could cause additional and erroneous
samples to occur; as Howard says, the frequency at which the RJ will
alias is not given - I agree.
So, RJ requires bandlimiting for this to work.
Tom
-----Original Message-----
From: Howard A. Baumer [mailto:hbaumer@xxxxxxxxxxxx]
Sent: Wednesday, August 01, 2001 9:43 AM
To: HSSG_reflector (E-mail)
Subject: 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