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