Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.

	-----Original Message----- 
	From: brian.cruikshank@xxxxxxxxxxxxx 
	Sent: Wed 8/15/2001 4:14 PM 
	To: Lindsay, Tom 
	Cc: anthony.sanders@xxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx 
	Subject: RE: AW: [802.3ae] XAUI Rj TR comment

	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: 
	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 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 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? 
	"Lindsay, Tom" <tlindsay@xxxxxxxxxxxxxxxxxxxx> 

08/14/01 11:19 PM 

        To:        <brian.cruikshank@xxxxxxxxxxxxx>,
        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
	questions was discussed (and agreed upon) via 99-618v0. Therein,
	will see that tolerance testing really wants to test over the
	ranges of edge rates, jitter, and amplitude that would be
allowed by the
	specs. C.2 inappropriately restores edge rates with the limiting
	and so does not stress sensitivity to slow edges as may be seen
	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
	edges and degraded amplitude, but adds amplitude noise, not just
	(possibly not a bad thing for harsher testing, but not
considered in the
	specs). Also this method would lead to some pattern dependent RJ
	is not realistic. Hence, the thought about adding RJ into the
	generator input
	The RJ spectrum must go well beyond any tracking bandwidth of
	receiver being tested. C.2 was trying to say that the upper
	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
	believe this is truly necessary as long as consideration is
given for
	what spectrum may actually be seen. The lower end is not
	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
	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
	 a controlled edge rate is required for the clock signal to for
	conversion (sine is good).
	 the amplitude of the clock signal must drive the generator well
	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
	Hope some of this helps.
	Thanks, Tom Lindsay
	                -----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
	                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
	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
	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
	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
	Sent by: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx 
	08/12/01 01:18 PM 
	       To:        stds-802-3-hssg@xxxxxxxx 
	       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
	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
	and to make some statements about this and about the current
Annex 48B. 
	                - The Annex 48B, currently refers to the MJS
	                - 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,
	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
	of a working channel at 1e-12 BER. At this BER the variance of
	gaussian tail and it´s offset (or effective DJ) are what defines
	                - 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
	DJ), some from the bandlimiting of the channel (DDJ), and the
rest from
	crosstalk or other phenomina in the channel (high frequency DJ).
	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
	                - If someone tries to use receive equalisation,
in conjunction
	with a receive signal that contains either high amount of random
	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
	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
	signal. The data is sampling the random bandlimited noise (not
	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
	Obviously from a test setup point of view, it is a good idea to
	sure that the RJ has a low pass filter with a corner frequency
	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
	tolerance testing. Testing with HF DJ is worse case, in
comparison to
	                - 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
	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
	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