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

[brian.cruikshank@xxxxxxxxxxxxx]

Tom,

Thanks a lot.  I am starting to understand.  It took me a little while to find the presentation you referred to that updates the MJS document.  For others here is the location: ftp://ftp.t11.org/t11/pub/fc/mjsq/99-618v0.pdf.

I have some new questions now.

Below you mention that the white noise RJ needs to be well above the PLL frequency but does not have to be all the way up to 1.5 Ghz.  Is this the consensus of the group.  It looks from Section 47.3.4.5 that the low frequency of RJ is 20 Mhz, but no high frequency is specified yet.  If the high frequency does not have to be 1.5Ghz, then should it changed in 47.3.4.5 and Annex 48B and a number agreed upon?

Below you mention bandlimiting on the summed signal.  If the clock source is frequency X.  What would you filter the output signal with?  It seems that if you filter too much you loose some of the jitter.  If you filter too little, you may have some erroneous clocks.  If the high frequency RJ (around 1.5Ghz) is not needed, I suppose this problem becomes easier.

Is there any early version of the new Annex 48B available?  or when is Draft 3.2 going to be available?

/Brian

"Lindsay, Tom" <tlindsay@xxxxxxxxxxxxxxxxxxxx> 08/14/01 11:19 PM

To:        <brian.cruikshank@xxxxxxxxxxxxx>, <anthony.sanders@xxxxxxxxxxxx>         cc:        <stds-802-3-hssg@xxxxxxxx>         Subject:        RE: AW: [802.3ae] XAUI Rj TR comment

Brian - let me attempt some responses.
 
Portions of the MJS document our already out of date. Figure C.2 is one
such item. After publication of the report, much of the scope of your
questions was discussed (and agreed upon) via 99-618v0. Therein, you
will see that tolerance testing really wants to test over the combined
ranges of edge rates, jitter, and amplitude that would be allowed by the
specs. C.2 inappropriately restores edge rates with the limiting amp,
and so does not stress sensitivity to slow edges as may be seen in
copper systems. It also restores amplitude, same comment.
 
If the limiting amp is removed, then a different method is required to
introduce RJ. Simply adding it in with a hybrid coupler retains slow
edges and degraded amplitude, but adds amplitude noise, not just jitter
(possibly not a bad thing for harsher testing, but not considered in the
specs). Also this method would lead to some pattern dependent RJ which
is not realistic. Hence, the thought about adding RJ into the pattern
generator input
 
The RJ spectrum must go well beyond any tracking bandwidth of the
receiver being tested. C.2 was trying to say that the upper frequency
end must be at least 500 MHz (this was for 1.0625 Gbd testing, so scale
as appropriate), but per the 1st sentence of this paragraph, I don't
believe this is truly necessary as long as consideration is given for
what spectrum may actually be seen. The lower end is not critical,
although RJ calibration must be done with the effects of a golden PLL in
place. (I may a little off on this without looking at the document; also
revision 3.2 may be worded a little differently...).
 
As far as adding RJ at the CLK input:
  use a high power random noise source with an RF attenuator to control
RJ magnitude.
  be sure the random noise source does not clip the tails before 1e-12 -
this is a tough one.
  bandlimiting of the source is required to prevent double clocking.
  a controlled edge rate is required for the clock signal to for AM/PM
conversion (sine is good).
  the amplitude of the clock signal must drive the generator well into
limiting before the shift register section.
  a 2x1 hybrid coupler works, but be sure it has the appropriate
frequency response.
  be sure the CLK input has sufficiently wide BW for the RJ to pass
through.
  
Hope some of this helps.
 
Thanks, Tom Lindsay
Stratos
 

                 -----Original Message----- 
                 From: brian.cruikshank@xxxxxxxxxxxxx 
                 Sent: Tue 8/14/2001 3:12 PM 
                 To: anthony.sanders@xxxxxxxxxxxx 
                 Cc: stds-802-3-hssg@xxxxxxxx 
                 Subject: Re: AW: [802.3ae] XAUI Rj TR comment
                 
                 

                 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

winmail.dat