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

XAUI Jitter Protocol 21st Febuary 2001

To: "Serial PMD reflector (E-mail)" <stds-802-3-hssg-serialpmd@xxxxxxxx>
Subject: XAUI Jitter Protocol 21st Febuary 2001
From: Anthony Sanders <anthony.sanders@xxxxxxxxxxxx>
Date: Thu, 22 Feb 2001 00:27:52 +0100
Organization: Infineon Technologies
Reply-To: anthony.sanders@xxxxxxxxxxxx
Sender: owner-stds-802-3-hssg-serialpmd@xxxxxxxx

Please find included 

1) XAUI Jitter Protocol 21st Febuary 2001
2) Update XAUI Jitter Issue List

Best regards,

Anthony Sanders
Principal Engineer
Infineon Technologies
Munich, Germany

XAUI Jitter Protocol
21th Febuary 2001

Attendants :

Rich Taborek <rtaborek@xxxxxxxxxxx>,
Tom Lindsay <Tom.Lindsay@xxxxxxxxx>
Schelto vanDoorn <schelto@xxxxxxx>,
Frank Barber <Frank_Barber@xxxxxxxxxxxxxx>,
Kesling Dawson W <dawson.w.kesling@xxxxxxxxx>,
Jeff Porter <j.porter@xxxxxxxxxxxx>,
Tord Haulin <tord.haulin@xxxxxxxxxxxxx>,

0. Current comments to D2.1

Issue Section Page section line type comment proposal
------------- ---- ------- ---- ---- ------- --------

Discussed and agreed :

2.5.3 279 47.3.3 40 Tech 100 ohm load is under-specified +/-5% (>30 dB RL to 2.5 GHz)
1.2 285 47.3.4.4 3 Tech Low freq break should accomodate packet Change lower corner in figure 47-8 from
125 kHz and 1.5 UI to 22.1 kHz and 8.5 UI.
2.5.1 Jitter Methodolgy not defined Addition of Annex 48B
2.5.4 286 47.4.1.2 38 Tech Eye undefined Remove section. Current data eye should show eye with and without
3.2 281 47.3.3.5 31 Tech Near-end Jitter components underdefined TJ<=0.35UI, DJ<=0.18UI.
SJ. Annex 48B should refer to this dataeye for compliance testing.
3.3 284 47.3.4.4 45 Tech Spectrum of RJ unconstrained Received random jitter is defined as being above 20MHz with a
20dB/dec rolloff at lower frequency. It should be noted that the
random jitter is naturally bandlimited at higher frequency by the
sampling nature of the data.
4.6 281 47.3.3.4 3 Tech 10 dB RL is excessively restrictive 10dB <= FBaud/2, 8dB > FBaud/2
4.6 284 47.3.4.3 34 Tech 10 dB RL is excessively restrictive 10dB <= FBaud/2, 8dB > FBaud/2
4.7 281 47.3.3.5 29 Tech 100 kHz limit on group delay too low Group delay definition to be removed
and a minimum DJ should be defined that must be induced by the
channel, for a given pattern, and transmit waveform.
4.8 S11 for channel not defined S11 = tbd @ 2.5GHz should be defined.
281 47.3.3.5 11 Tech Far-end Jitter components underdefined TJ<=0.60UI, DJ<=0.36UI.
Add "Jitter" section 47.3.3.x and add to table 47-2.

Not discussed but should be entered :

281 47.3.3.5 24 Tech Excessively restrictive to spec to DC TBD
286 47.4.1 12 Tech Annex.48B.X not referenced fully TBD (Same applies to lines 16, 19 and 24.)
286 47.4.1 15 Tech Table x.x not referenced fully TBD
286 47.4.1 17 Tech "combined ... filter" not clear TBD
2.5.3 286 47.4.1.1 33 Tech Termination undefined Reference 47.3.3 for termination in 47.4.1.
Remove 47.4.1.1 and editors' note.

To be entered :

277 47.1.2 22 c Edit 7 cm implies excessive accuracy Change "7 cm" to "10 cm".
278 47.2 8 c Edit "Table" should not be capitalized Change "Table" to "table".
278 47.2 16 c Edit Editors' note no longer needed Remove editors' note.
279 47.3.3 40 c Edit "Table" should not be capitalized Change "Table" to "table".
280 47.3.3.3 30 c Edit CM RL of 5 dB disagrees with text Change "5" to "6".
281 47.3.3.5 11 c Edit "Table" and "Figure" shouldn't be cap. Chance to lower case.
281 47.3.3.5 17 Edit "transmission magnitude" is ackward Change to TBD throughout document.
281 47.3.3.5 17 c Edit First occurance of "ISI" unclear Replace "ISI" with "intersymbol interference (ISI)".
282 47.3.3.5 38 c Edit Figure 47-6 confusing Move x-axis to bottom of template.
283 47.3.4 39 c Edit Editors' note no longer needed Remove editors' note.
283 47.3.4 36 c Edit "Table" should not be capitalized Change "Table" to "table"
284 47.3.4.4 42 c Edit "Table" should not be capitalized Change "Table" to "table".
284 47.3.4.4 45 c Edit Gaussina discussion inappropriate Remove "Assuming a Guassian ... 5.5 ps RMS."
286 47.4.1 28 c Edit Space mising between "XAUI" and "shall" Add space.

No Comment Necessary :

10 283 47.3.3.5 2 Tech Min amplitude of template OK? No comment necessary
6.4.1 286 47.4.1 27 Tech CJPAT suitability for transmiter No comment to be entered

------------------------------------------------------------

A- All above comments to be entered (Dawson)

1.2 Very low frequency jitter definition frequency and amplitude

A- Comment to be entered

Tom to send email concerning explanation of difference between low
frequency jitter and clock tolerances of 100ppm clock tolerance.
Agreed.

2.5.1 Annex 48B

A- Comment should be raised for addition of Annex 48B

A- An additional Annex shall be written to cover methodology

- Anthony to take over Annex48B outline. Rich.T to send Ant. a
initial frame for outline.

2.5.3 Termination Section

A- Comment to be entered
Agreed.

2.5.4 Receive Compliance Data Eye

A- Receive eye needs to be shown with and without sinusoidal jitter.

- Rx Tolerance Methodology
- Set 200ppm offset between transmit and receive clock
- Enable all channels in transmit and receive direction
- Using CJPAT
- Transmitter + DJ + RJ -> Channel -> Rx Data Eye
- Calibrate DJ and RJ of Rx Data Eye to confirm to specified
receive jitter
- Adjust Output level of Pattern Generator such that Eye
Amplitude = Channel Rx Eye
- Verify Rx Data Eye vs. Receive Data Eye Mask without SJ
- Add specified SJ for given frequency
- Adjust Output Level of Pattern Generator such that Eye
Amplitude = Channel Rx Eye
- Verify Rx Data Eye vs. Receive Data Eye Mask with SJ
- Verify BER of Reciever

3.2 Transmit jitter

A- Comment to be entered

3.3 Random Jitter

A- Comment to be entered

Transmit RJ not to be bandlimited.

Normative Definition of RJ :

Received random jitter is defined as being above 20MHz with a
20dB/dec rolloff at lower frequency. It should be noted that the
random jitter is naturally bandlimited at higher frequency by the
sampling nature of the data.

4.4 FEXT/NEXT (Cross Talk)

A- Crosstalking specifications from typical connectors to be
collected from connector manufacturers by Rich and Ali.

A- Shelto to provide datasheets for typical connectors to Dawson,
who will draw some conclusions.

A- Theoritical simulation of expected differential crosstalk to be
done (Anthony)
- Problems with simulation software leading to delay in results.

4.6 Return Loss

A- Proposal to be entered for transmit and for receiver
- 10dB <= Baud/2, 8dB > baud/2

4.7 Group Delay of Channel

A- Comment to be entered that Group delay definition to be removed
and a minimum DJ should be defined that must be induced by the
channel, for a given pattern, and transmit waveform.

4.8 S11 for channel definition

Although it may seem to make no sense in defining RL, as for channel
compliance a worst case RL is required, for a system designing
wishing to design a PCB that should work with two already available
chips; the designer must know how good the performance of the
channel must be. To this end the S11 must be defined.

A- Comment should be entered, exact numbers to be set in next telco.

6.4.1 Compliance Definition

- Adhoc to remain with use of CJPAT and HPF for compliance testing.
- Refer to emails from Tom.L to be included in Jitter Issue List.

A- Matlab phase model to verify use of HPF and CJPAT (IFX)

10. Overall Verification of Jitter Budget

A- Ongoing simulations for verification of newly proposed jitter
numbers and patterns are ongoing by
- Dawson
- Compliance Channel eye is looking open, figures to be released
soon.

XAUI Jitter Issue List

21th Febuary 2001

Goals of Adhoc :

1. Define Jitter Mask for transmitter.

2. Jitter measurement methodology Golden PLL or TIA.

3. Jitter penalty of channel. The pattern K28.5+/- is sufficent
pattern to test the channel, since K28.5 has 101 transition as well 5
consecutive ones or zeros.

4. Jitter tolerance for component is well established, but for systems
difficult to implement and beyond the scope of this group. We will
define the basic jitter tolerance testing requirement and jitter
patterns.

5. Jitter compliance for pre-emphasis driver with Golden PCB. Would
be sufficient for a pre-emphasis driver to just meet the jitter
specification of receiver at 0" and at 20" with golden PCB?

6. Pattern for compliance for example K28.5+/-, FC CJTPAT, or FC
CRPAT.

Contents :

0. Comments for D2.1

1. Jitter Tolerance Mask
1.1 Break frequencies and amplitudes
1.2 Very low frequency jitter definition frequency and amplitude
1.3 Receiver J

2. Jitter measurement methodology
2.1 Termination Methodology
2.2 FC definitions for methodology. (contribution by Tom Lindsay)
2.2.1. Jitter definitions
2.2.2. Signal Integrity for testing
2.3 Manufactures Standard Test Definition
2.4 Jitter Compliance Equipment
2.5 Section and Annex
2.5.1 Annex 48B
2.5.2 Clause 47
2.5.3 Termination Section
2.5.4 Receive Compliance Data Eye

3. Transmit Jitter
3.1 Transmit data eye X1, X2 (difference)
3.2 Transmit jitter
3.3 Random Jitter

4. Additional Jitter Budget
4.1 .....
4.2 BUJ (Boundied uncorrelated jitter)
4.3 DJ from Channel Compliance
4.4 FEXT/NEXT (Cross Talk)
4.5 Connectors & VIAS (Current budget probably not enough)
4.6 Return Loss

5. Equalised Compliance Testing

6. Compliance Patterns
6.1 Jitter Strategy
6.1.1 Purpose of jitter test patterns:
6.1.2 Test equipment limitations
6.1.2.1 Pattern generation for receiver test:
6.1.2.2 XAUI transmitter jitter measurement:
6.1.3 Pattern types
6.1.4 Summary:
6.2 Basis of FC Jitter Pattern (contribution from Tom Lindsay)
6.2.1 PURPOSE/BACKGROUND
6.2.2 PATTERN CONTENT
6.2.3 PATTERN LENGTHS
6.2.4 OTHER NOTES
6.3 Random Jitter Measurement of K28.7
6.4 Defined patterns
6.4.1 Compliance Definition
6.4.1.1 Background for CJPAT and HPF for compliance (Tom Lindsay)
6.5 Test Equipment for Pattern Compliance testing

7. BER definition

8. Instantaneous Bit Shift

9. SONET SJ

10. Overall Verification of Jitter Budget

------------------------------------------------------------

0. Current comments to D2.1

The following points should be discussed and agreed upon as being
comments to come from the XAUI Jitter Adhoc. (see summary of
comments in attachment).

Issue Section Page section line type comment proposal
------------- ---- ------- ---- ---- ------- --------

Discussed and agreed :

Not discussed but should be entered :

To be entered :

No Comment Necessary :

10 283 47.3.3.5 2 Tech Min amplitude of template OK? No comment necessary
6.4.1 286 47.4.1 27 Tech CJPAT suitability for transmiter No comment to be entered

------------------------------------------------------------

1. Jitter Tolerance Mask

1.1 Break frequencies and amplitudes

f_c / 1667, and f_c / 25000 corner frequencies are still
open. Agilent shall make more comments to the reflector and also
raise a comment to the specification concerning this issue. However,
it would seem the majority are still in favor of keeping the
frequencies as current proposed by Ali. This issue remains open.

Allan has researched in some detail where the current corner
frequencies and amplitude come from, but has currently not being
able to pin anything down.

There appears to be a frequently referenced document "Bell Labs
Technical Report (�92)" that Allan is trying to aquire. Dawson
suggested that Allan also contact Adam Healy.

A- Find FC white paper on investigation leading to SWAG number of
0.1UI and 1.5UI for amplitudes. (Allan) This action point shall be
closed upon studying of the Bell Labs document.

An upper frequency limit of the jitter tolerance, was suggested by
Mysticom. However, after discussion it is clear that there is some
confusion within the Fiber Channel specification, and the 5MHz is
only a pratical limit. The jitter tolerance of 0.1UI should extend
up to infinity.

Movement of the upper frequency limit break for the jitter tolerance
recieved no support in LA (Jan).

Proposal to limit upper limit of SJ to 20MHz, due to limitations in
measurement equipment was accepted by LA (Jan) group.

1.2 Very low frequency jitter definition frequency and amplitude

- Basic fundimentals of FIFO calculations for low frequency jitter
available from Shelto.

http://grouper.ieee.org/groups/802/3/ae/public/adhoc/
serial_pmd/jitter_documents/2clocks.pdf

- Extend down to 22kHZ, with 20dB/dec, and then cap down to DC,
agreed by telco.

A- Comment to be entered

1.3 Receiver J

- Current TJ=0.65UI, DJ=0.41UI
- 0.41UI is really limits for SerDes design. (comment from Hari
working group, Ali)

- Concerns from Ali, and Eyan state that Receive DJ of 0.41UI plus
the jitter tolerance of 0.1UI for high frequency will give a Total
DJ of 0.51UI which is too high. This point must be discussed this
week.

Proposal to reduce recieve DJ to 0,36 and TJ to 0.6 accepted by LA
(Jan) group. This then allow for the additional 0.1UI of SJ during
testing.

------------------------------------------------------------

2. Jitter measurement methodology

2.1 Termination Methodology

- Only DUT and Measurement equipment, no tap adaption not required.!
- Conversion from 150 to 100, not required, only ever 100
- AC Coupling is standard therefore need to define ac coupling
capacitance and termination resistor values and tolerance.
- Only have balanced signals, therefore methods defined for balance
to unbalanced signals should be adopted, but of course with 100ohm.

2.2 FC definitions for methodology. (contribution by Tom Lindsay)

In the 12/20 conference call, I noted two important conclusions
within Fibre Channel that have followed publication of the MJS
technical report (99-151v2):

2.2.1. Jitter definitions

That simple pk-pk is unsufficient as the requirement for DJ; that an
overall weighting function that captures not only the pk-pk but the
shape of the density function is required for DJ; that this may be
known as "effective DJ" and that it (and "effective RJ") are
determined or derived from the bathtub curve. Curve fit methods have
been suggested (see 99-489v0 and 99-488v0, and Annex A.3 in revision
10 of FC-PI (00-645v0)).

99-464v0 discusses this issue by comparing pk-pk DJ specification
vs. effective DJ specification. Note: in 99-464v0, effective DJ is
proposed/based on a dual-delta function (see Annex A of the MJS
technical report). This can be thought of as square wave or
bang-bang jitter. 99-464v0 uses DCD (duty cycle distortion) as an
example of square wave jitter.

Pages 12 & 13 provide the conclusions of 99-464v0.

Also see Figure C.1 in the MJS technical report.

2.2.2. Signal Integrity for testing

That tolerance testing should include not only jitter but also at
least amplitude and rise/fall time settings. Figure C.2 in the MJS
report only induces jitter - amplitude and rise/fall times are not
specified, but the implication from Figure C.2 is that the test
signals are directly transmitted from a limiting amplifier.

99-618v0 attempts to address this issue. In particular, refer to
pages 2, 4, 8, & 20.

Page 8 shows a recommended test configuration that imposes
simultaneous jitter, slow rise/fall times, and amplitude
closure. Also,

- the sine wave frequency must sweep to well above the corner
frequency of available CDR circuits.

- depending on its internal functioning, a limiting amplifier may be
required ahead of the pattern generator.

- the random noise generator spectrum may want to be wider for the
XAUI rate.

Page 20 notes that sine jitter (SJ) is added to the tolerance signal
AFTER the other jitter, amplitude, and rise/fall time
characteristics are calibrated. This additional jitter term not only
adds jitter but further reduces the amplitude opening. This effect
has been since captured in FC-PI (see 00-645v0, Figure 34).

Page 20 also notes that jitter (DJ/RJ) is calibrated using the
high-pass-filter (HPF) function (i.e., DR/1667) AND using the
effective jitter concept discussed above. Note - high-pass filtering
and effective jitter are required for ALL jitter measurements,
whether for output compliance testing of tolerance calibration
(except SJ). See pages 13 & 14 of 99-618v0 for examples of the
application of the the HPF and effective jitter (shown as "curve
fit").

2.3 Manufactures Standard Test Definition

The question of whether the compliance testing method should this be
beter defined by chip designers and possibly entered in a
specification or white paper, did not gain favor.

The issue of specification of operating conditions was raised by
Optillion, however it is the pratice of IEEE specification not to
define any environmental conditions. These issues should be covered
by the PICS Performers.

2.4 Jitter Compliance Equipment

Note from Ron Miller referring to possible equipment that can be
used for jitter measurement.

MainFrames needed:
86100A DCA
or 83480A DCA

Clock Recovery Modules:
83491 2.5 Gbs Electrical Clock recovery module
or 83492A 2.5 Gbs Multimode Clock recovery module.

?- Questions exist from Ali concerning whether these device will
under estimate jitter due to bandlimiting effects.

2.5 IEEE Sections, Annex�s and References

2.5.1 Annex 48B

- It has been decided that Clause 47 and 48 shall not reference the
99-151v2 for methodology due to
- It�s status as an international standard
- The need for clarification of many jitter terminology
- Large majority of document is directed at FC
- References for methodology would be manditory

- Annex 48A shall continue to reference 99-151v2 as merely an
historical reference showing the basis for the calculation of the
various patterns.

A- An additional Annex shall be written to cover methodology
- Editor : Rich.T
- Editor job taken over by Shelto.
- Editor job taken over by Anthony
- Technical Inputs : Ali, Tom.L, Mike.J, Anthony.S
- This Annex shall take inputs from the following documents

- 99-151v2 :
- Annex A Bit Error Rate vs. Jitter Model
- Annex B Jitter Tolerance Test Methodologies.
- Annex C Jitter Output Test Methodologies

- 99-464v0 :
- Clarification of effecive DJ
- Model for effective DJ being delta pulse, due to it�s ease
of curve fitting.
- Effective DJ should cause no problems with measurement
equipment (e.g wavecrest)

- 99-618v0
- Definition of realistic eye for reciever tolerance
compliance testing vs. limiting amplifier output.
A- Realistic eye definition must still be defined, and will
results from simulation results of compliance channel.
- Use of HPF for calibration of receiver tolerance jitter,
input signal
- Use of complex patterns and HPF for transmit eye compliance
testing.
- Compliance testing of transmit data eye at both ends of
cable, for 0" and 20" setup.
- It has been recommended that the case of a manufacturer
providing programmable equalisation shall not be considered
by the specification, but only the statement that the
receive eye must be guarenteed at all channel lengths, and
0" and 20" must be tested manditory. (Current simulation
results from Infineon show that for a fixed equalisation or
no equalisation, conformation at 0" and 20", also guarentees
confirmation at length inbetween).

2.5.2 Clause 47

- Section for Clause 47 written by Anthony Sanders for D2.1. See
draft specification.

2.5.3 Termination Section

A- Comment to be entered

- Termination for measurement of jitter shall refer to 47.3.3 Driver
characteristics, which must be updated to include tolerance of +/-5%

2.5.4 Receive Compliance Data Eye

A- Receive eye needs to be shown with and without sinusoidal jitter.

------------------------------------------------------------

3. Transmit Jitter

3.1 Transmit data eye X1, X2 (difference)

Currently specification is wrong,
Defined is X1=0.175UI, X2=0.415UI (Aligent)
Proposal from Ali, X1=0.175UI, X2=0.365UI
Comment from Mike, X1=0.175UI, X2=0.380UI
LA Proposal, X1=0.175UI, X2=?
A=400mV, B=800mV

X2 is based upon assumptions of certain rise and fall
times. Agilent performed initial investigation based on a simple
trapazoidal, with additive noise. Ali proposal is more based upon
realistic waveforms with rounded corners. Agilent would have no
objections to new X2 numbers.

Mike Jenkins completed investigation of basis for X1, X2 values.
Please refer to reflector for details.

3.2 Transmit jitter

Currently defined DJ 0.17UI, TJ 0.35UI

P- Proposal from Infineon to wait until XAUI Compliance Channel is
defined to allow Jitter Budget to be completed.

!- Ongoing concern from Ali and Eyad concerning total jitter
tolerance (see emails).

- Allan sent the PWL input waveform used for the Agilent simulations
to Anthony to enable analysis of the current Compliance Channel
S21. (04Jan00 Data from Allan received)

Proposal LA (Jan), and general opinion. Current jitter specification
is hard already and should be left as is.

- Deterministic jitter for transmitter should be specified and not
only informative. This should include a comment concerning
transmitter with equalisation having to comply to receive jitter
requirements.
A- Comment to be entered

3.3 Random Jitter

A- Comment to be entered

Transmit RJ not to be bandlimited.

Normative Definition of RJ :

------------------------------------------------------------

4. Additional Jitter Budget

4.1 .....

4.2 BUJ (Boundied uncorrelated jitter)

This noise source is covered by SJ margin.

4.3 DJ from Channel Compliance

- Data from Ali (without connectors and for 16") shows measured data
eye for 2.5Gbps and 3.2Gbps. However, S21 transfer data is a little
more optimistic in comparison to the current available data from the
compliance group. 2.5G data eye show 0.1UI DJ, and for 3.125G approx
0.11UI. Confirming the current numbers in the 802.3 specification.

- Initial worst case S21 figures from Dawson received. Transfer
function being transfered into MATLAB model for generation of data
eye for evaluation of DJ. (Anthony)

LA (Jan) simulations from Mysticom and IFX show that the WC
Compliance channel as supplied by Dawson is giving too much
amplitude attenuation, given a value transmit eye.

XAUI group has decided to currently accept a average channel from
the measurement data, although concerns still exist that the current
data may still be best case when one starts looking toward thicker
backplanes. (The method of layer connection and via stacking being
one of the most critical parameters). In addition a maximum group
delay of 80ps was defined.

- Dawson supplied polynomial for the transfer function.
A- Jitter group must decide whether to accept min/max channel
compliance, and new jitter numbers. (See Complete Model)

- From initial simulation (IFX) an upper frequency of 3.125GHz for
the S21 information would seem to be sufficient. Question exist
concerning the phase response for upper frequencies. Also, it is
important that the attenuation has then an upper limit defined
>3.125GHz.

- The losses in the interface shall be defined for the channel and
for other losses (e.g crosstalk). The other losses shall be 2,5dB
flat across the entire bandwidth. Channel loss being approx 7,5dB
for 2.5GHz.

After verification of the IFX simulation results by one of the other
groups, a final decision shall be made to accept the proposed
compliance channel.

4.4 FEXT/NEXT (Cross Talk)

Crosstalking effects consists of the following phenomina

- Amplitude to phase noise
- Direct DJ
- Supply crosstalk
- Other chip crosstalk

Currently defined as 0.4% of 800mV, or 0.07 TJ, and x.xx DJ.

Crosstalk could be a big issue as loosely coupled differential strip
lines are currently seen as the preferred solution for the XAUI
Channel. This leading to increased differential noise issues. Also
it is a concern that crosstalk at connectors could be high.

Common mode noise could be also be converted to DJ at the reciever.

Comment from Ali, that connector shall be the biggest form of
crosstalk.

A- Crosstalking specifications from typical connectors to be
collected from connector manufacturers by Rich and Ali.

A- Theoritical simulation of expected differential crosstalk to be
done (Anthony)

A- Shelto to provide datasheets for typical connectors to Dawson,
who will draw some conclusions.

4.5 Connectors & VIAS (Current budget probably not enough)

Currently it would seem that current assumption concerning channel
may be too optimistic. (PCB Loss with connectors looks more like
-15dB stat. -10dB.)

Initial work from Aglient work did not include connectors

- Comment from Ali is that XAUI goal was 16". (Confirm).
- Confirmed is that XAUI goal is 20" (Ali, Rich)

- PCB with connectors are being assessed by compliance group, and
will be covered in some form (see current worst case channel
compliance S21 figures).

- Connector tolerances

4.6 Return Loss

Concerns exists concerning current RL specification.

- Verification of max/min capability of RL required. Distance of
the first connectors from the driver should be verified for WC.

- Proposal first raised by Jeff Cain and Tom Grey

The initial simulation results of IFX using the compliance channel
and estimation for 1/4lambda connectors would show an acceptable
data eye given a return loss of -8dB. This results should again be
verified by one of the other simulations current being run by Jeff,
or Tom.

A- ("Ishwar Hosagrahar" <ishwarh@xxxxxx>) to take over action of
providing nformation concerning this requirement.
- Perhaps RL for receiver should be left at 10dB.

- Comment from Ron Miller. (see below)

************************************************************
Hi anthony

I just got back from boston so could not join your concall.

However, when I read your agenda my hair stood on end. 8 db
should
not be a consideratiopn for Return loss.

If it should be changed it should be tightened up to 18 db and
should cover the frequency band from 200 Mhz to 10 Ghz. If
anyone makes equipment that poor(8db) I can assure you that all
the other system specs will be violated with 10E-12 ber
available only for inch length traces. There are some real bad
trade-offs here.

Please post this for comments.

Ron Miller
************************************************************

A- Proposal to be entered for transmit and for receiver
- 10dB <= Baud/2, 8dB > baud/2

4.7 Group Delay of Channel

A- Comment to be entered that Group delay definition to be removed
and a minimum DJ should be defined that must be induced by the
channel, for a given pattern, and transmit waveform.

4.8 S11 for channel definition

A- Comment should be entered, exact numbers to be set in next telco.

------------------------------------------------------------

5. Equalised Compliance Testing

The use of the compliance channel (including random noise) and
receive jitter budget for the compliance testing of an equalised
transmitter was agreed upon and fixed.

------------------------------------------------------------

6. Compliance Patterns

6.1 Jitter Strategy

6.1.1 Purpose of jitter test patterns:

To be used for verifying compliance to Clause 47 jitter
specifications for XAUI transmitters and receivers.

Patterns for other jitter-related purposes are not subject
to standardization.

Requirements and desirable properties:

- Expose all reasonably significant weaknesses that could
cause interoperability problems due to jitter effects.

- Stimulate all four lanes

- Simple to generate from test equipment and XAUI circuits

- Simple to analyze in test equipment and XAUI circuits

6.1.2 Test equipment limitations

6.1.2.1 Pattern generation for receiver test:

A differential four-channel pattern generator with individual
control of pattern, amplitude and timing on each 3.125Gbit/s
channel would be the ultimate instrument for testing XAUI
receivers. In lack of one, other options must be investigated.
I have found single-channel complementary and two and four-channel
single-ended generators. Since they have ample amplitude ranges
power splitters can be used to create four differential lanes.
The output signals from the splitters can be de-skewed and filtered
by twisted pair cables to introduce ISI jitter for eye degradation.
With the two-channel generators, patterns are limited to columns
of identical or inverted (crossed) bit-patterns. A fair amount of
testing can be done that way. A four-channel generator offers more
options. Two of the channels can be operated complementary and
split 1:3 to be used as aggressor channels with identical data,
while the remaining two channels are used for the victim channel.

Conclusion: There should at least be a set of patterns specified
which are limited to equal or inverted data columns across the
XAUI lanes.

6.1.2.2 XAUI transmitter jitter measurement:

The tails of the edge timing distributions can be extrapolated
down to 10e-12 with a TIA or BERT scan. Measured on one channel
at a time, at transmitter output or end of reference channel.
Full 3.125Gbit/s rate must be supported for full exposure of
transmitter ISI.

Conclusion: The transmitter must generate a pattern with a fair
amount of ISI-exposing K28.5 or equivalent.

6.1.3 Pattern types

XAUI protocol compliant patterns offer the advantage of some
freedom in choice of locations for pattern generation and
analysis. I don't see a need for specifying non-compliant
patterns, neither for coverage reasons or because of measurement
methods or equipment limitations.

Both wide spectrum (random)-type patterns and CDR test patterns
of CJTPAT type can be fit in compliant frames.

The XAUI IDLE pattern generator has a fairly well spread spectrum.
By detailed standardization of the algorithm, it can be used in
a random pattern test. It is compliant and can go on forever
without the limitations of packet residing patterns. It's short
enough to allow the receiver to hunt for synchronization without
a marker. It comes for free on the transmitter side.

The CJTPAT assumes that clock recovery PLLs will have phase lock
equilibria at different extremes for a 1010101... pattern vs.
a 111110000011111... pattern. Repeating them long enough for the
phase locked loop to stabilize at the extreme will then constitute
the largest systematic risk for a bit error when moving from one
to another. In some cases patterns of the K28.5 type will probably
be worse as successors to long periods of any of the first two
patterns. With some care in putting together a CJTPAT type pattern
that case can easily be taken care of.

6.1.4 Summary:

Patterns with CRPAT and CJTPAT properties can be made compliant
in four-lane versions for XAUI.

Test equipment limitations can restrict the possibilities for
generating patterns exposing many kinds of cross talk.

Test of lane de-skewing capabilities delay adjustment capabilities
beyond the readily available. Yet, such a test would probably be
the most demanding for a receiver CDR.

6.2 Basis of FC Jitter Pattern (contribution from Tom Lindsay)

6.2.1 PURPOSE/BACKGROUND

Low frequency (within the passband of the CDR PLL) variations in
transition density may be combined with ISI jitter or mechanisms
internal to the CDR, such as phase detector offset. The CDR may track
these variations, and low frequency jitter can occur within the
CDR. CJTPAT was developed to test for such situations. After each
tracking due to a run of low or high transition density, the CDR is
hit with bit sequences associated with the opposing jitter. Because of
the tracking, the peak jumps in jitter are more severe than if the
tracking had not occured. This in turn may lead to higher bit error
rate.

6.2.2 PATTERN CONTENT

CJTPAT includes:
6x FC IDLEs (24 characters)
SOFn3- (4 characters)
Payload (228 characters, including header)
CRC (4 characters)
EOF (4 characters)

For Ethernet, obviously the 6x IDLEs, SOF, and EOF will have to
change. The payload is really what we're after.

The payload consists primarily of 7E's and B5's. However, transition
characters also exist. These transition characters are VERY IMPORTANT
to the pattern.

167 7E's (30% transition density, minimum sustainable in 8B10B)
1 74
1 7E
1 AB
51 B5's (100% transition density, maximum sustainable in 8B10B)
1 5E
1 4A
4 7E's
1 FE
Total = 228 characters (57 FC words)

Looking at the attachment, there are particular bit sequences that
occur. These are highlighted in red.

The first is in the transition between the 167 7E's and the 51 B5's:
In the 74, a single 1 occurs after a string of 4 0's;
then a few more wide-spaced sequences occur;
in the AB, a single 0 occurs after a string of 4 1's.
The second transition sequence is after the 51 B5's:
in the 5E, 4 contiguous 0's occur after ...0101;
then a few more 1010... sequences occur;
in the 1st of the 4 7E's, 4 contiguous 1's occur after ...1010.

These transitions are what make CJTPAT interesting. The long repeating
runs (167 7E's and 51 B5's) are used to move the CDR alignment over,
but then these particular bit sequences maximize the phase jumps that
give the sample and hold circuits their challenges. So, don't attempt
to build the pattern without these transitions.

6.2.3 PATTERN LENGTHS

I assumed that one might design their CDR corner frequency to be as
low as DR/1667. If we convert that corner frequency into a time
constant (assuming a single pole model), the time constant is approx
267 bits or 26.7 characters. The average transition density for 8B10B
code is approx 60%, so the time constant can be converted to approx
160 data transitions.

For CDR shifting to be complete (~95%), at least 3 time constants are
required for settling.

(The next part may be controversial). Most CDRs show a straight
dependence between bandwidth and transition density - that is, time
constant is inversely proportional to transition density, or settling
is directly proportional to the number of data transitions. If the CDR
exhibits a "corner frequency" of DR/1667 at 160 transitions, then

3 time constants at 100% transition density (the B5's) results in 3
x 1bit/transition x 160 transitions = 480 bits = 48 characters.

3 time constants at 30% transition density (the 7E's) results in 3 x
3.3bits/transition x 160 transitions = 1600 bits = 160 characters.

After building up the pattern, I used a few more of each, mostly
because of additional constraints of least common multiples with FC
words and bytes for BER testers.

If folks feel this relationship with CDR bandwidth and transition
density is not valid, then pattern lengths can be adjusted.

6.2.4 OTHER NOTES

1. Starting running disparity is important. The first 7E in the long
run MUST start with POSITIVE running disparity so the correct
character (1000011100) is taken from the table. Otherwise, the
transition sequences do not work.

2. The last character is FE. This was chosen to determine a CRC that
ended in positive running disparity, so that the FC EOF used the
alternate disparity (1100000101) of the K28.5 (FC IDLEs and SOF all
use 0011111010). This is probably not critical (see below), but
provides both polarities of the comma.

3. Worse case bit patterns are possible if K characters are allowed,
but CJTPAT was constrained to be a valid FC frame. K characters were
not allowed in the middle of the frame. For example, the 4 0's
followed by a single 1 is the worst case situation of this type
allowed with D characters. The 5 0's followed by single 1are provided
in the pattern at its ends, but these are less interesting because the
CDR's will be somewhat re-centered when they occur.

6.3 Random Jitter Measurement of K28.7

An open question concerning the ability to measure random jitter
using the K28.7 code was clarified. The K28.7 code in combination
with normal data eye methods is prone to picking up bounded
uncorreleted code. Use of BERT methods are therefore recommended for
RJ measurements.

6.4 Defined patterns

- The current Annex 48B proposal contains the following patterns.
- High Frequency (short) : RJ
- Low Frequency (short) : RJ + PLL Tracking
- Mixed Frequency (short) : RJ + DJ
- CRTPAT (long) : Overall jitter in system
- CJTPAT (long) : Jitter tolerance

- Patterns based on FC and GigaEthernet
- Patterns are 8b10b specific, and do not cover scrambled, or 64b66b
based data
- Proposal covers problems of independant lanes
- High, low and mixed frequency patterns same as FC
- Needs a little work on Pattern run length
- Patterns transmitted on each channel should be same and
sychronised for each channel.
- Long patterns should be generated at MAC level. Using methods for
generation of patterns in Recieve direction similiar to FC.
- Short patterns are generated with register enabling. Please note
these patterns must be manditoryly generated.
- Disparity on each four lanes could be different
- Opinion is that this does not need to be controlled
- Half pattern runs with +ve parity and half with -ve

- Non 8b10b patterns shall be left out of specification.
- Additional SPAT and CSPAT should not be needed

A- Final acceptance of proposed pattern.

Tom.L has sent via the reflector a proposal for the CJTPAT, based
on the inputs from Mysticom, conforming to the required packet
length. The pattern is generally accepted for compliance testing of
the XAUI interface, however, up until the next Plenary comments
should be sent to the reflector

A- It was requested that Rich could possibly explain how the
compliance pattern can be generated from MAC.

6.4.1 Compliance Definition

The following points are currently agreed.

- Only a single pattern should be defined for compliance.
- The majority of manufacturers shall implement the ability to
transmit simple 8b10b code words i.e High/Mixed/Low frequency
patterns.

The following points must still be discussed in some more detail, on
the reflector.

- CJTPAT for transmitter DJ and RJ compliance.
- CJTPAT will give different numbers in comparison to short
patterns. This means that the currently defined jitter numbers
may have to be adjusted.
- Transmitter must be capable of generating the CJTPAT. This
could be accomplished through BERT Scan, or MAC.
- Consistency in results of DJ and RJ using such long patterns.
- Complexity of such transmit patterns.
- Using same pattern for transmit and receive compliance should
guarentee better compliance between devices.

- Use of CJTPAT as a receive tolerance pattern causing a worse
case jump in the CDR, in comparison to other simple
patterns. (minor point as it would seem clear that this is the
case.)

- A note of caution from Ali
- Pattern should not be too complicated and long as this can
lead to complication with measurement equipment.
- Pattern should be such that implementors can use this
- Mixed Frequency or K28.5 could be sufficient
- Serial PMD, current using simple scrambler pattern with
additional influence from A0/A1 bytes for (WAN PHY)
- Does CJPAT require other jitter budgets.

- Adhoc to remain with use of CJPAT and HPF for compliance testing.
- Refer to emails from Tom.L to be included in Jitter Issue List.

A- Matlab phase model to verify use of HPF and CJPAT (IFX)

6.4.1.1 Background for CJPAT and HPF for compliance (Tom Lindsay)

Fibre channel (FC) understood that CDRs track low frequency jitter,
and that including this effect in the specifications could ease
requirements on clock oscillators (lower cost designs tend to
exhibit low frequency random jitter), serializer (serdes, same
advantage) designs, and switching power supplies, layouts,
bypassing, etc. With all this in mind, all FC jitter output
specifications include the effects of a high-pass filter (to
suppress the significance of low frequency jitter) to emulate CDR
tracking.

FC also realized that, due to frequency content, long complex
patterns cause phenomena that are not observed with short patterns -
data dependent jitter (DDJ, a form of deterministic jitter) can have
extreme ranges of frequency content from well below to well above
the CDR corner frequency. Effects are usually seen in both
transmitters and receivers. Since such long complex patterns (such
as CJPAT) can exist in real systems, they must be included somewhere
in a set of specifications for a standard.

Some observations:

- High pass filtering (HPF) is appropriate for the reasons given
above. If HPF is used, then (at least in some test methods), HPF
will naturally also be applied to DDJ.
- Without HPF, due to transmitter interactions, long complex
patterns usually result in worse pk-pk DDJ output than
+/-K28.5s, although differences are typically <10%.
- With HPF, I have observed that CJPAT-type patterns can
increase pk-pk DDJ by more than 50%. However, when considering
equivalent (bathtub curve-fitted) deterministic jitter, this
increase will be somewhat reduced in relation to the amount of
random jitter present.
- In any case, HPF emulation implies that CDRs will have more
trouble with CJPAT than +/-K28.5s, and I have observed this in
the lab with CJTPAT.
- Jitter budgeting must be based on long patterns, since they
are more challenging and represent likely scenarios in real
systems. However, this still leaves open the debate on test
methods, data patterns, and jitter test limits. That is, it may
be possible to have jitter test limits that are different than
the jitter budget.

Now, for the debate - assuming that HPF is used (do we want to
debate this one?), data pattern options are:

Jitter output :
Short pattern :
- Set tighter test limits to anticipate greater
jitter output so that long patterns still stay
within the budget.
- The amount of tightening will take some thought,
and will be a function of random jitter, etc.
Long pattern (CJPAT) :
Set test limits based directly on the budget.
Jitter/signal tolerance :
Short pattern :
- Set test conditions worse than the output jitter
budget to anticipate the receiver's response to long
patterns.
- The amount of increase will take some thought and
will be a function of random jitter, Rx bandwidth,
etc.
Long pattern (CJPAT)
- Set conditions equal to output specs, which in
turn are based directly on the jitter budget.

4 combinations exist from above. My opinion is probably obvious: use
long patterns for ALL jitter budgeting and specifications in the
standards.

- Using the same pattern for everything provides a
self-consistent set of specifications, and making it a long
pattern helps ensure that real mechanisms in real systems are
flushed out.
- The first role of the standard should be technical rigor -
ahead of simplicity.
- Let test simplification be an option to those implementing the
standard at their own risk and benefit. Specifically, leave
the interpolation/extrapolation required with short patterns to
those who truly understand their own products and are interested
in simplifying their test environments. They are free to do so.
- The standard does not have to deal with the non-trivial task
of determining relationships between a jitter bugdet and test
limits across a range of technologies and products yet to be
developed.

6.5 Test Equipment for Pattern Compliance testing

- Additional points to proposal
- Independant timing skew for each of the four channels is really
needed.
- Testing one channel independantly to the other channels could be
too worst case!!! as this would lead to a possible high low
frequency jitter between channels.
- Compliance test should try cover all the possible phenomina in
one test, as opposed to trying to seperate out phenomina. (This
can be done for diagnostics).
- Can standard IDLE pattern generator could be used as random
pattern generator.

------------------------------------------------------------

7. BER definition

Currently the XAUI interface is defined as having a quality of
10e-12, this gives an equivalent of 14xRMS for peak-peak jitter to
give 10e-12 on single channel basis, but what is required for 10e-12
over all four uncorrelated channels. This point must be clarified.

In various meeting we have discussed BER of a lane vs the channel.
The basic assumption here is you are sending 4 times the amount of
data and 4 time the error rate, the resulting error rate still
remains 1E-12. Even if you look from the point of a packet getting
zapped the probability remain the same 1E-12 as a packet takes 1/4
of time to cross a XAUI channel.

Extention of discussion to complete BER expected from concatenated
XAUI-Optical-XAUI links, each defined as having a BER of 1e-12 is
not practically interesting.

- Quantify better Rich�s concerns concerning the BER of the XAUI
link wrt PMD link. (next telephone conference). The question of
overall BER for the 10Gbe link was discussed again in LA, and the
issue of total overall BER was consider outside the bounds of
measurement.

------------------------------------------------------------

8. Instantaneous Bit Shift

A serious concern raised is associated with possibility of 0.65 UI
of instantaneous jitter causing bit shift. In the original Hari
proposal due to this concern the maximum DJ was limited to 0.41 at
the receiver and 0.17 UI at the transmitter. (Comment from Ali)

This issue was discussed in the Hari group and the total DJ was
limited to 0.41 UI because of instantaneous jitter. Even 0.41 UI is
already challenging for many SerDes designs. (Comment from Ali)

------------------------------------------------------------

9. SONET SJ

In the traditional SONET the only required specification on the
receiver is for tracking low frequency. In addition it was
requested the random component of XAUI link be specified so it will
not be concentrated at one frequency specially near the bit
rate. (Comment from Ali)

SONET link only specify SJ for jitter tolerance, which is easier to
meet than full DJ+RJ with FC scaled SJ. SONET specifies 0.15 UI of
SJ at after the right most break and FC specifies 0.1 UI, but with
FC you have the additional DJ+RJ. SONET link primary concern is
jitter generation and transfer. In the case of copper link you will
have high amount of high frequency ISI, therefore we need to limit
the instantaneous high frequency.

Trying to specify the random jitter such that it will not be
concentrated at one frequency will be difficult to verify and test.
You would need to use phase noise measurement with multiple filter.
If we want to add an specification here it should only be based on
viewing the relative noise spectrum, not trying to measure RJ as
function of frequency. Even this will be challenging as the
oscillator phase noise will broaden each of data peaks.

------------------------------------------------------------

10. Overall Verification of Jitter Budget

- Polynomial available from compliance group.

A- Ongoing simulations for verification of newly proposed jitter
numbers and patterns are ongoing by
- Jeff Cain
- Tom Gray
- IFX
- See below
- Mysticom
- See below
- Jeff Porter
- No resources available
- Dawson

Use of high pass filtering when assessing the transmit eye should be
used when assessing long patterns to account for tracking behavior.

Methods for inclusion of maximum group delay in simulations should
be assessed carefully.

Additional amplitude noise should not be forgotten about when
assessing the simulation results for receive eye.

Simulation results from IFX :

showed various setups using the compliance channel, reduced return
loss and additional connectors at 1/4 lambda distances from
transmitter and receiver.

The following comments were made

- The data eye should be regenerated, with a single eye to give
a complete data eye
- The method for the positioning of the data eye should be
explained.
- If possible confirmation of CJTPAT with a HPF
- The model is "really" worst case
A- The source of the X2 for the receive data mask should be
explained in the coming weeks.
- It is vital that confirmation of these simulation results from
the other participants be made available as soon as possible.

The following conclusion can be current drawn

- The proposed channel can be accepted
- The proposed group delay deviation can be increased to 200ps
- The return loss can be relaxed to -8dB
- The proposed SJ of 0.1UI is acceptable
- There would appear to enough margin for additional amplitude
noise

Simulations results from Mysticom :

- Results from simulation from Mysticom (available from IEEE
internet page).
- Results look positive for current specified channel, however,
simulation is not for CJPAT and does not include PLL tracking
phenomina.

Status from Dawson :

- Simulations just started. Matlab generated trap. waveform, with
Gaussian RJ and LP eye to give DJ. Ideal driver with termination
resistor and capacitance, and lumped ladder model for channel,
with lumped connectors. Alterating K28.5 pattern used.
- Compliance Channel eye is looking open, figures to be released
soon.

Follow-Ups:
- XAUI frequency tolerance time window
  - From: Tom Lindsay

Prev by Date: Re: XAUI skew
Next by Date: XAUI skew
Prev by thread: =?utf-8?B?UkU6IFhBVUkgc2tldw==?=
Next by thread: XAUI frequency tolerance time window
Index(es):
- Date
- Thread