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