Re: AW: [802.3ae] XAUI Rj TR comment

[brian.cruikshank@xxxxxxxxxxxxx]

Anthony,

I have some questions about your comments below and the MJS document.  Hopefully you can help me out.

- The MJS document Figure C.2 is adding the RJ by adding a white noise source after the BERT or pattern generator.  In your comments below, it sounds like you propose changing that white noise source to be added to the BERT clock source.  Is this correct?

- In Figure C.2, the White Noise Source is specified as 500Mhz<Bandwidth<1Ghz.  Does this mean that all frequencies are between 500 Mhz and 1Ghz or does this mean that the top white noise frequency is between 500 Mhz and 1 Ghz?  I think your comments below seem to indicate that it is the latter.  If it is the latter, is the bottom end of white noise source supposed to be the PLL corner frequency of 1/1667?

- Is there a recommended method to adding this white noise source to the BERT clock source?  Does this white noise source exist or can it be created with a known circuit?

I appreciate any help you can give.

/Brian Cruikshank

anthony.sanders@xxxxxxxxxxxx Sent by: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx 08/12/01 01:18 PM

To:        stds-802-3-hssg@xxxxxxxx         cc:                 Subject:        AW: [802.3ae] XAUI Rj TR comment

Appologies from my side, as well for not having also come in on this subject at an earlier date, but for those following the current financial situation in Europe, you will know we have been worrying about other things for the last few weeks.

After reading through the 20..30 emails on this subject, I would like to get back to the original problem that Howard is putting forward, and to make some statements about this and about the current Annex 48B. 

- The Annex 48B, currently refers to the MJS documents.
- We have agreed this annex would be updated to remove the references and remove inconsistencies, and I will in the next week, once I recieve some inputs from Michael Debie (Wavecrest) about TIAs, have this ready. Anyone intersted in commenting on it before the next interim, please email me.
- The Annex 48B, defines, based on MJS what is meant by RJ and DJ i.e effective RJ and effective DJ
- Effective DJ/RJ is a valid/easy/understandable and safe method for defining jitter.
- Effective DJ/RJ can at high BER show a high inaccuracy to other methods of measuring or defining DJ/RJ, but the question is "Who cares?". We are interested in defining a model that allows confirmation of a working channel at 1e-12 BER. At this BER the variance of the gaussian tail and itīs offset (or effective DJ) are what defines this.
- There is currently an ambiguity during receiver tolerance testing that someone can set all the DJ to RJ, which of course is wrong. Some of the DJ comes from the driver (normally DCD or high frequency DJ), some from the bandlimiting of the channel (DDJ), and the rest from crosstalk or other phenomina in the channel (high frequency DJ). Please note that we treat the RJ of the channel as "other" DJ, to add margin in the design.
- If one tries to set up a jitter tolerance test with a high amount of RJ, this can lead to problems, as Howard is explaining.
- If someone tries to use receive equalisation, in conjunction with a receive signal that contains either high amount of random jitter OR high amounts of HF DJ this will also give problems (We do not try to define anything concerning receive equalisation, however the specification does allow for the use of receive equalisation; a receiver should be allowed to equalise out the DDJ from channel if it wants to).
- Adding large amount of RJ at the clock input to a BERT, with no bandlimitation will give problems, as the RJ is a rotation vector of amplitude and time, and will lead to the problem that Howard is describing. (However, the question is should we add so much RJ.... we come back to this)
- The RJ as it is seen be the receiver is sampled and does therefore show the appropriate spectrum associated with a sampled signal. The data is sampling the random bandlimited noise (not random white noise, otherwise one would not see any sampling effect), and is therefore giving rise to bandlimitation at half the sampling rate, plus up and down converstion (one reason for not increasing the bandwidth of the receiver must higher than the currently defined 1/1667.)
- One main concern in the test setup is that the RJ is above the 1/1667 corner frequency in the test setup. If the correct test method is used, i.e. with a "Golden PLL" for the calibration of the signal, then bandlimiting of the RJ at the input to the BERT is not a problem. Obviously from a test setup point of view, it is a good idea to make sure that the RJ has a low pass filter with a corner frequency above half the baud rate.
- It is clear that the driver should be allowed to have all of itīs deterministic jitter converted to random jitter, as the DJ is in anycase high frequency. However, this has nothing to do with receive tolerance testing. Testing with HF DJ is worse case, in comparison to RJ.
- The channel introduces DDJ, and this should not be allowed to be converted into RJ
- The channel introduces HF DJ, and this can be converted into RJ, but again has nothing to do with receive tolerance testing. Again DJ is worse case for testing, in comparison to RJ.
- For the purpose of testing, we need to possibly do some small modifications. The calibrated signal, could therefore consist of 
                 SJ = Driver DJ + Channel Other (introduced with the SJ source)
                 DJ = Channel DDJ (introduced through bandlimiting of the signal
                 RJ = Driver RJ (introduced using bandlimited RJ noise at input to BERT generator)

This is a little different to before, but would be more accurate for taking into account receive equalisation, and also the trade off of DJ to RJ.

I hope this is reasonably acceptable to everyone, it doesnīt agree with everyone comments, but is in my view pretty close to reality. Howard, could you inform me if this is acceptable.

Appologies in advance for any loss of grammer in the above email, it got a bit longer than I wanted.

Anthony Sanders
Principal Engineer
Infineon Technologies