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.
 
Tom

	-----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
	
	

	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