RE: [802.3ae] XAUI Rj TR comment
> Tom,
>
> In the threshold front end of one of these receivers I thought you only got
> a sample when the PLL clock clocked the circuit? If that's the case then,
> other noise pulses that would cause transitions before or after the clock
> would not result in an output? What am I missing here?? Please be gentle.
> . .
>
> Dennis
Hi Dennis,
With respect to this, a correct answer depends on the specific type of CDR
implemented. In most cases these will include two distinct parts: a data
latch/flip-flop, and a phase detector. Your answer is correct for
the data latch portion, but not for the phase detector.
The phase detector should respond to any transition in the data stream,
and provide an output proportional to the offset in phase of that transition
relative to the internal clock.
Regards,
Ed Grivna
>
> -----Original Message-----
> From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, August 01, 2001 3:22 PM
> To: HSSG_reflector (E-mail)
> Subject: 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