RE: [802.3ae] XAUI Rj TR comment
See below, Tom
-----Original Message-----
From: Howard A. Baumer [mailto:hbaumer@xxxxxxxxxxxx]
Sent: Tuesday, July 31, 2001 11:36 AM
To: Lindsay, Tom; HSSG_reflector (E-mail)
Subject: 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.
**TL - I'd be for it. In my experience, it will be largely limited by
the serializer passband. I suppose if someone was trying to deserialize
off the back end of an optical link there will be some higher frequency
RJ, but I am no fan of doing that. Imposing frequency content may
further discourage folks from trying it.
- 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.
**TL - what I didn't understand is what mechanism allowed it to get
through. I really don't need to know. Again, I fixed all this with an
input limiting amp before the clock input.
- Whether or not receive side equalization boost the high frequencies is
determined by its implementation.
**TL - I understand, but it seems that this boost would aggravate the
effects of a large magnitude of high frequency RJ. See below.
- We're still confused on how you would ever get 0.55UI of RJ. If
crosstalk adds so much jitter,
**TL - crosstalk is expected to be bounded, and therefore more
effectively deterministic (the definition of RJ is unbounded/Gaussian to
least below 1E-12, and DJ is all other stuff).
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?
**TL - clause 47 does not currently prescribe nor has it allowed for Rx
equalization. This was known and intentional. Is this getting back to
the equalization question above?? Is this the core of the issue?
Also, you ask about using the same clk as the Tx - a deserializer will
use the clock as a reference clock, but isn't the recovered clock used
for deserialization running in a different clock domain than the Tx?
Certainly one can't use a lousy Rx clocking scheme and expect
compliance.
- We indicate the RJ rms addition with the "+rms" symbol. Since we
assumed the RJs are not correlated we had to rms add them.
**TL - thanks, I did not understand the symbols before.
- 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.
**TL - okay.
- 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.
**TL -
a. Are you budgeting for sampler setup and hold, offset and uncertainty,
or this what you consider part of Rx DJ and RJ?
b. If not, then in leaving 0.1 for DJ generation in the Rx, I calculate
that the Rx can generate up to 0.39 UJ RJ and still keep below 1.0 TJ at
the decision point (0.9 .
Tom
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 |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~