[802.3ae] XAUI Rj TR comment and beyond--
A twist of the thread - the other was getting beaten to death!
Anthony - other than a couple of tiny picks, I generally agree with all
in your message. However, I would like to react a bit to your proposal
for tolerance testing.
Recognizing that a RANGE of signal and jitter combinations will be seen
in applications, I personally believe that testing at least 2 points
over a range is appropriate. As such, I am uncomfortable documenting
only a single test condition in the standard. In my FC work, my first
point combined min edge rates and max DDJ from high channel attenuation
& ISI, minimum amplitude, additional RJ as needed to achieve TJ, and
finally application of SJ (test for slow and/or poor sensitivity Rx).
The other point included max edge rates and min DDJ, max RJ to achieve
TJ, then finally SJ (test for over-equalization and/or overdrive
problems, etc.). I assumed if I would operate at these 2 extremes, then
I had a good chance of working in between.
I need to reiterate - with some risk of not being inclusive, these were
my choices, required to avoid testing all possible combinations. These
choices were not suggested in any way by the standard.
Therefore, I would still like to see a range implied for receivers.
Furthermore, the choice of actual test setup(s) MUST be left up to
developers and not specifically called out in the standard, otherwise
developers will optimize to the setup(s) and not to the range of actual
applications. Our challenge should be to define the signal range(s) as
we have been doing, not the test conditions. We just have to get the
numbers right.
So, back to Howard's original issue, I am not against limiting the
frequency content and/or amplitude of RJ spec for XAUI. I too mentioned
(to Dawson) the thought about holding the amplitude to the driver value.
This seems to be the simplest answer.
Your suggested set of Rx test values seems reasonable, but many others
are possible. Their exclusion must be a risk-choice of the developer.
Thoughts?
Finally, I plan to soon send a related email that suggests that IC
developers may want to think carefully about limiting RJ tolerance
capability because of possible usage in optical links.
Thanks, Tom
Stratos
-----Original Message-----
From: anthony.sanders@xxxxxxxxxxxx
Sent: Sun 8/12/2001 12: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
>>>>clip<<<<
winmail.dat