Re: [802.3ae] XAUI Rj TR comment
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 |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
begin:vcard
n:Baumer;Howard
tel;work:(949)450-8700 x1817
x-mozilla-html:TRUE
org:Broadcom Corp.
adr:;;16251 Laguna Canyon Road;Irvine;California;92618;
version:2.1
email;internet:hbaumer@xxxxxxxxxxxx
title:Engineering Networking
x-mozilla-cpt:;-1
fn:Howard Baumer
end:vcard