Re: AW: [802.3ae] XAUI Rj TR comment
Anthony,
I agree with all of your analysis. However, I disagree with the basic
premise that you make about receive equalization. IEEE P802.3ae does not
support receive equalization in any form for any interface. More
specifically, XAUI does not support receive equalization. Therefore, no
changes should be made to the D3.2 in response to any outstanding
comments which claim an inability to support XAUI receive equalization.
All such comments must be rejected in the interest of meeting P802.3ae
objectives.
I believe that receive equalization is the basic premise for all XAUI Rj
comments. If I am wrong, then any argument for supporting XAUI receive
equalization in any manner must be purged from any discussion of XAUI Rj
comments. I strongly urge all 802.3 voters to consider this argument.
The purpose of the following background material is to explain XAUI
operation in the presence or absence of equalization:
--
The reason is that supporting receive equalization would be an
interoperability nightmare with negative cost/performance implications
and no apparent advantage in meeting XAUI objectives. Consider that the
Clause 47 XAUI spec already supports either no equalization or transmit
equalization. Simulation, theoretical calculations and actual operation
all clearly show that simple transmit equalization, more accurately
described at transmit de-emphasis, yields a reach improvement of >>50%
over a XAUI compliant channel (e.g. XAUI PCB traces, etc.). It should be
noted that XAUI objectives of 20" over common FR-4 have been proven to
be met with no equalization at the transmitter or receiver.
XAUI specified transmit equalization simply enables additional XAUI
reach in a cost effective manner compatible with XAUI receive
specifications. Permitted XAUI configurations currently include:
1) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
2) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
3) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
4) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
All four configurations above must support at least 20" over common
FR-4. My sense is that virtually all XAUI implementations will utilize
configuration 4 which supports transmit equalization on both XGXS sides
in order to keep power at a minimum while meeting or exceeding XAUI
objectives. It is my experience that most if not all XAUI vendors
support transmit equalization at no cost premium over no equalization.
XAUI transmit equalization simply de-emphasizes lower frequency signals
with respect to higher ones. Since XAUI signals are 8B/10B based, the
highest frequency signal is at 1/2 Baud (1.5625 GHz) and the lowest
frequency is 1/10 Baud (312.5 MHz). The de-emphasis is with respect to
signal amplitude. Transmit equalization implementation is not specified
by Clause 47 only either transmit and receive or receive only templates
must be met. However, one of the simplest, cost effective and time
tested approaches to transmit equalization is the reduce the amplitude
of lower frequency signals with respect to higher frequency signals. The
following example illustrates one of the simplest forms of transmit
equalization, reducing the amplitude of the 2nd consecutive signaled bit
of the same value (i.e. zero or one). Please use a fixed width font to
display anything meaningful.
--+ +---+ +--+ +-//
| | | | \ | //
| | | | +------+ | //
| | | | | | //
| | | | | | //
| | | | | | //
| | | | | | //
| | | | | | //
| | | +--+ | | //
| | | / | | //
+---+ +--+ +---+ //
1 0 1 0 0 1 1 1 0
Note that the signaling above is logical and not representative of the
physical differential signaling over XAUI.
Receive equalization was rejected as unnecessary in meeting XAUI
objectives, not cost effective and not interoperable during XAUI
development. If receive equalization were to be allowed at this late
point in P802.3ae development the permitted XAUI configurations would
include:
1) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
2) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
3) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
4) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
5) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
6) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
7) DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
8) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - No Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
9) DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
10)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
11)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
12)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - Tx Eq
13)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
14)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - No Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
15)DTE XGXS Tx - Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
16)DTE XGXS Tx - No Tx Eq -----XAUI-----> PHY XGXS Rx - Rx Eq
DTE XGXS Rx - Rx Eq <---Channel---- PHY XGXS Tx - No Tx Eq
I trust that the above clearly portrays the interoperability nature of
adding receive equalization to XAUI at this late juncture. Note also
that the addition of receive equalization to XAUI must be considered a
major technical change to P802.3ae and must be considered out of order
as the cut off for last P802.3ae feature was November 2000 and the cut
off for the last P802.3a technical change was May, 2001.
In conclusion, any development or changes to XAUI or Rj methodology must
not consider receive equalization.
Best Regards,
Rich
--
anthony.sanders@xxxxxxxxxxxx wrote:
>
> 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
>
> -----Ursprüngliche Nachricht-----
> Von: Mike Li [mailto:mpeng@xxxxxxxxxxxxx]
> Gesendet am: Freitag, 10. August 2001 21:48
> An: 'Jonathan Thatcher'; HSSG_reflector (E-mail)
> Betreff: RE: [802.3ae] XAUI Rj TR comment
>
> Can anyone kindly tell me where is the current XAUI jitter
> document and the agenda/plan for the future activities?
>
> Thanks !
>
> Mike
>
> Wavecrest
>
> > -----Original Message-----
> > From: Jonathan Thatcher
> > [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
> > Sent: Thursday, August 09, 2001 4:32 PM
> > To: HSSG_reflector (E-mail)
> > Subject: RE: [802.3ae] XAUI Rj TR comment
> >
> >
> >
> > Kesling,
> >
> > Thanks for the redirection. Regarding the activity to define
> > these terms,
> > please be aware that the jitter test methodology being used
> > in clause 52 is
> > substantially different than the prior art referenced here from Fibre
> > Channel and Gigabit Ethernet. Most of the concepts are the
> > same (from a
> > theoretical perspective), but much of the similarity ends there.
> >
> > I do not recommend that the XAUI group use this new method
> > (though it should
> > provide some advantages). But, please be aware and understand
> > it during the
> > course of refining the definitions.
> >
> > jonathan
> >
> > > -----Original Message-----
> > > From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> > > Sent: Wednesday, August 08, 2001 12:03 PM
> > > To: HSSG_reflector (E-mail)
> > > Subject: RE: [802.3ae] XAUI Rj TR comment
> > >
> > >
> > >
> > > All,
> > >
> > > I've been watching the reflector discussion but have been too
> > > busy to reply.
> > > I'd like to quickly give some background to help clarify the
> > > situation.
> > > Please don't shoot me - I'm only the editor giving some history!
> > >
> > > It has been universally understood in the XAUI group (until
> > > recently) that
> > > DJ is everything bounded and RJ is everything unbounded.
> > > Furthermore, RJ has
> > > been assumed to be Gaussian for the purspose of calculations.
> > > Sinusoidal
> > > jitter (SJ) is a subset of DJ. XAUI does not treat it
> > > differently from DJ,
> > > but only calls out an explicit level for the SJ component of
> > > DJ. Jitter that
> > > is bounded but not correlated to the data is also
> > deterministic by the
> > > working definition. XAUI does not call this out explicitly,
> > but other
> > > clauses may.
> > >
> > > Many people came into XAUI from different backgrounds, but
> > > agreed to these
> > > definitions for the sake of normalization and communication.
> > > The work done
> > > in MJS was helpful to XAUI and was the basis for these common
> > > definitions.
> > > Those who have more recently become active in XAUI seem to be making
> > > different assumptions about the definitions of these jitter
> > > terms. Other
> > > definitions may be valid, but we should not change the underlying
> > > definitions agreed to by dozens of participants and approved
> > > in several
> > > draft ballots at this late stage. There is nothing wrong
> > with the XAUI
> > > definitions as long as they are defined. The real problem is,
> > > as Pat pointed
> > > out, that they are not well defined in the document. This has
> > > always been
> > > intended to be done in Annex 48B but has not been finished
> > > yet. I belive
> > > that Anthony Sanders and Tom Lindsay are still working on it.
> > > This annex
> > > needs to be finished and submitted in the upcoming ballot
> > > cycle so that
> > > newcomers and standard readers can understand the meaning of
> > > DJ and RJ as
> > > used in XAUI (and the other clauses).
> > >
> > > In summary, I do not think there is anything inherently
> > wrong with the
> > > definitions assumed by XAUI and being written into Annex 48B
> > > (based on MJS).
> > > We should all use these definitions and get on with the
> > > HOward's real issue
> > > of limiting the RJ as the term has been defined by the group.
> > > Please forgive
> > > me that I probably won't be able to reply to any further
> > > e-mails on this
> > > topic. I only hoped to refocus us on the important issue
> > > while I had a spare
> > > minute between fires.
> > >
> > > -Dawson
> > >
> > >
> > > -----Original Message-----
> > > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> > > Sent: Monday, August 06, 2001 4:58 PM
> > > To: Dennis Petrich; THALER,PAT (A-Roseville,ex1); Lindsay,
> > Tom; Howard
> > > A. Baumer; HSSG_reflector (E-mail)
> > > Subject: RE: [802.3ae] XAUI Rj TR comment
> > >
> > >
> > >
> > > Dennis,
> > >
> > > The MJS document is referenced from an informative part of
> > > our draft and it
> > > is a TR. The terms are used in normative specifications in
> > > our draft. The
> > > definitions should be added to our draft because a
> > > specification doesn't
> > > mean anything if the quantity being specified is left ambiguous.
> > >
> > > Regards,
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Dennis Petrich [mailto:dpetrich@xxxxxxxxxxxxx]
> > > Sent: Wednesday, August 01, 2001 2:11 PM
> > > To: 'THALER,PAT (A-Roseville,ex1)'; Lindsay, Tom; Howard A. Baumer;
> > > HSSG_reflector (E-mail)
> > > Subject: RE: [802.3ae] XAUI Rj TR comment
> > >
> > >
> > >
> > > Pat,
> > >
> > > The NCITS "TR-25-1999" MJS document provides definitions that can be
> > > referenced for XAUI use to distinguish between the various
> > > jitter types such
> > > as RJ, DJ, DDJ, SJ and so on.
> > >
> > > Also, FC crosstalk work was done a while back and can be viewed at
> > > T11/00-064v0 and T11/99-759v0. In the tests crosstalk showed
> > > up as DJ. But
> > > I'm sure these results would vary as a function of the
> > > crosstalking data
> > > rate and frequency content.
> > >
> > > Dennis
> > >
> > > -----Original Message-----
> > > From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> > > Sent: Wednesday, August 01, 2001 1:43 PM
> > > To: Lindsay, Tom; Howard A. Baumer; HSSG_reflector (E-mail)
> > > Subject: RE: [802.3ae] XAUI Rj TR comment
> > >
> > >
> > >
> > > Tom,
> > >
> > > Jitter always seems to be a difficult subject to sort out and
> > > your remark
> > > below caused me to do some checking on RJ vs. DJ.
> > >
> > > I've looked all through the 802.3 standard and our draft.
> > > There doesn't seem
> > > to be any definition of RJ or DJ. Processes can certainly be
> > > random without
> > > being random or Gaussian. Deterministic means if a set of
> > > conditions is set
> > > up we know what will result. The roll of a die is random
> > > though the result
> > > is bounded.
> > >
> > > If we are using dictionary words with a different or more
> > > restricted meaning
> > > such as random = Gaussian (or truncated Gaussian where the
> > truncation
> > > happens past 1E-12) then we should define our terms. Since
> > we specify
> > > deterministic jitter and total jitter, we should at least
> > > have a reasonably
> > > rigorous definition of "deterministic jitter."
> > >
> > > I also notice that in some places jitter is divided into RJ
> > > and DJ, but in
> > > other places in 47 it is RJ, DJ and sinusoidal. 52.9.10.4 (and the
> > > equivalent subclause of 53) divide jitter into random,
> > > deterministic and
> > > bounded.
> > >
> > > Crosstalk is deterministic in that given a fixed adjacent
> > > signal and a fixed
> > > coupling function one can determine the crosstalk. However,
> > > the crosstalk at
> > > a receiver is often the result of multiple disturbers
> > > coupling in each with
> > > its own function and the signals aren't correlated to the
> > > received signal.
> > > Therefore, the sum of the crosstalk looks like a truncated
> > > Gaussian. Even if
> > > the definition of RJ is Gaussian up to at least 1E-12, it
> > > isn't clear to me
> > > that crosstalk would fall outside that definition. I don't
> > > recall seeing any
> > > studies on the distribution of crosstalk for XAUI or for our optical
> > > receivers.
> > >
> > > I would expect crosstalk to be part of RJ rather than DJ.
> > >
> > > Regards,
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> > >
> > > See below, Tom
> > >
> > > -----Original Message-----
> > > From: Howard A. Baumer [mailto:hbaumer@xxxxxxxxxxxx]
> > > Sent: Tuesday, July 31, 2001 11:36 AM
> > > To: Lindsay, Tom; HSSG_reflector (E-mail)
> > > Subject: Re: [802.3ae] XAUI Rj TR comment
> > >
> > > >>>>snip<<<<<
> > > - We're still confused on how you would ever get 0.55UI of RJ. If
> > > crosstalk adds so much jitter,
> > > **TL - crosstalk is expected to be bounded, and therefore more
> > > effectively deterministic (the definition of RJ is
> > > unbounded/Gaussian to
> > > least below 1E-12, and DJ is all other stuff).