RE: AW: [802.3ae] XAUI Rj TR comment
Brian -
1. All the spec requires on RJ (presently) is that the integrated
magnitude be achieved by jitter that is above 20 MHz. No upper end is
stated or implied. Obviously if the upper frequency end is lower, then
the spectral density must be higher, and vice versa.
2. Without rigorous thought, I would think limiting spectral content to
below the data rate should be fine. Since it will later be aliased, 1/2
data rate is probably a better choice.
3. Not sure about 3.2 or Annex 48B. I'm waiting too.
Tom
-----Original Message-----
From: brian.cruikshank@mindspeed.com
Sent: Wed 8/15/2001 4:14 PM
To: Lindsay, Tom
Cc: anthony.sanders@infineon.com; stds-802-3-hssg@ieee.org
Subject: RE: AW: [802.3ae] XAUI Rj TR comment
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@stratoslightwave.com>
08/14/01 11:19 PM
To: <brian.cruikshank@mindspeed.com>,
<anthony.sanders@infineon.com>
cc: <stds-802-3-hssg@ieee.org>
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@mindspeed.com
Sent: Tue 8/14/2001 3:12 PM
To: anthony.sanders@infineon.com
Cc: stds-802-3-hssg@ieee.org
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@infineon.com
Sent by: owner-stds-802-3-hssg@majordomo.ieee.org
08/12/01 01:18 PM
To: stds-802-3-hssg@ieee.org
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