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

XAUI Jitter Telco Agenda 18th April 2001



Dear XAUI Jitter Telco'ers,

Same agenda as last week.


1- Today's telco should concerntrate on initially making sure that we are consistent with all the issues that were closed in Hilton Head, and which are still to be dealt with and reentered as comments for the next ballot. (approx 1/2hour) 

2- Discussion of major open electrical issues for XAUI (approx 1/2hour), e.g Group delay, electrical levels, ......

3- Lastly, if we have time, we should spend some time again agreeing upon what we discussed last week concerning the allocation of the additional channel jitter and the slight change in dealing with SJ and "Other" jitter in the system budget.

Please find attached summary of open issues extracted from the current XAUI Jitter Issue List, also attached.

Thanks for your participation and again please email me before hand if your name is not on the participation list.

Anthony Sanders
Principal Engineer
Infineon Technologies


Time : 9:30am (PDT), 18:30 (CET)
Toll free number (inside US) : 800 891 9585
International number : 865 525 3200
Participant Code : 674870
Time : 90mins
Ports : 15


 <<Attendant_18Apr01.txt>> 
 <<XAUI_Jitter_Agenda_18Apr01.txt>> 

 <<XAUI_Jitter_Issues_10Apr01.txt>> 

Anthony.sanders@infineon.com <anthony.sanders@infineon.com>,
Adam Healey <ahealey@lucent.com>, 
Bijit Patel <bijit_patel@pmc-sierra.com>,
Bob Smith <robert@hibandsemi.com>, 
Dennis Petrich <dpetrich@wavecrest.com>,
Jeff Cain <jcain@cisco.com>, 
Jim Hesson <jhesson@hessonlabs.com>, 
John Wright <john.wright@velio.com>,
Peter Dartnell <dartnell@nortelnetworks.com>, 
Richard Dugan <richard_dugan@agilent.com>, 
Ron Miller <rmiller@brocade.com>, 
Shawn Rogers <s-rogers@ti.com>,
Leo Wong <lwong@bitblitzcom.com>,
Jason Chen <jchen@bitblitzcom.com>, 
Allan Liu <allan_liu@agilent.com>, 
"Ishwar Hosagrahar" <ishwarh@ti.com>,
Joel Dedrick <Joel_Dedrick@pmc-sierra.com>,
Farzin Firoozmand <Farzin_Firoozmand@pmc-sierra.com>
Frank Barber <Frank_Barber@pmc-sierra.com>,
Doug.Day@taec.toshiba.com,
Ali Ghiasi <aghiasi@earthlink.net>, 
Robbie Shergill <robbie.shergill@nsc.com>,
Kesling Dawson W <dawson.w.kesling@intel.com>, 
Schelto vanDoorn <schelto@wco.com>, 
Rich Taborek <rtaborek@nserial.com>,
Tom Gray <tgray@tality.com>
Mike Jenkins <jenkins@lsil.com>,
"John Wright" <John.Wright@velio.com>
Michael Debie <MDebie@Wavecrestcorp.com>,
Jeff Porter <j.porter@motorola.com>,
jmw(Mike) <jmw@bayarea.net>
Tord Haulin <tord.haulin@optillion.com>, 
Tom Lindsay <Tom.Lindsay@vixel.com>
john.dambrosia@tycoelectronics.com

0. Current Comments To D2.1 

  A- summary of the classification shall be sent by Dawson to the
  reflector when appropriate.

1.1 Break Frequencies And Amplitudes
  
  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.

1.2 Very Low Frequency Jitter Definition Frequency And Amplitude

  A- Comment To Be Entered

2.5.1 Annex 48b

  A- Arrange tutorial (Ant)

  A- Updates to Annex 48b required (see Jitter Issues for more information)

  A- Tom to send out explanatory email concerning this curve fitting point.

  A- Tom to think about whether he wants to send something out.



2.5.2 Clause 47.4

  A- Final update of Clause 47.4 needed (see attachment at end)

  A- Make sure that Golden PLL, is not referenced, only HPF. (Allows for TIA).

  A- Includes reference in methodology conerning clock offsets and asynchronous clocks for transmit and receive paths.

  A- We need a note concerning where the data eye mask is position in the data eye!!!!!

  A- This should be added to data eye part of specification, or as clarification in Annex48B


2.5.3 Termination Section

  A- Comment To Be Entered


2.5.4 Receive Compliance Data Eye

    A- Receive Eye Needs To Be Shown With And Without Sinusoidal Jitter.


3.2 Transmit Jitter

    A- Comment To Be Entered


3.3 Random Jitter

  A- Comment To Be Entered

4.3 Dj From Channel Compliance

  A- Jitter Group Must Decide Whether To Accept Min/Max Channel
  Compliance, And New Jitter Numbers. (See Complete Model)

4.6 Return Loss

  A- ("Ishwar Hosagrahar" <Ishwarh@Ti.Com>) To Take Over Action Of
  Providing Nformation Concerning This Requirement.

  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.

  A- There is some work in progress toward a solution. (Note 1)

4.8 S11 For Channel Definition

  A- Comment Should Be Entered, Exact Numbers To Be Set In Next Telco.

6.4.1 Compliance Definition

    A- Must we add the DJ really together...??? We must somehow decide whether all this jitter is data dependant and correlated or not. This would allow us to use convolution, which may give as a few mUI here and there.
   A- Tom to repost information concerning effect of random jitter on effective DJ.
   A- Proposal to solve the current jitter specification. 
 	- Increase channel jitter to 0.2UI
   	- "Other" should be treated as SJ depending upon whether we are talking about compliance testing or system budget. 
	- Make "Other" 0.1UI for system budget to avoid confusion.



10. Overall Verification Of Jitter Budget

    A- Convertion of the SJ jitter from Giga into absolute time offset must be done (Ant)

13.1 Amplitudes

  A- Thought about above comments welcome

13.2 Differential Skew

  A- Comment to be entered and accepted.

13.3 Definition of ISI loss vs Other Losses

  A- Thought about above comment welcome


Xaui Jitter Issue List 

10th April 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 

  - Only comments concerning technical completness shall be accepted
  for Plenary. The author of the comment, shall be asked to defer his
  comment until the next ballot session, in May.

  - Therefore there will be 3 classes of comments. (Reject, reject
  until next plenary, accept for this plenary)

  (D) The draft standard was unanimously approved for 802.3 Working Group ballot. This indicates that the attendees believed the draft is "technically complete", meaning that further technical refinements are anticipated but there are no known technical holes r insurmountable barriers. W.G. ballot is scheduled to begin on April 6 and end May 11.

  A- summary of the classification shall be sent by Dawson to the
  reflector when appropriate.

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


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

  The sinuosoidal jitter that is currently defined for Jitter Tolerance, is capable of generating phase offset between channels that are greater than the demultiplexed 10b word boundary. This test however, is implementation and shall not be discussed anymore in this adhoc. 


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.

  Current Annex 48B was written in the Hilton Head Plenary by a breakout team.

  (D) The XAUI jitter methodology was discussed in detail and given a vote of confidence. Annex 48B was approved describing this methodology. (Presentation or clarifications needed.)

  The adhoc is of the opinion that due to the complexity of jitter and the current implications of the jitter methodology that is being defined, a Tutorial on jitter at the next available date would be advantageous in eduating both the commitee and help bring the current proposals to final specification. Michael Debie from Wavecrest volunteed equipment that could be made available for also demonstrated the methods described. 

  A- Arrange tutorial (Ant)

  Main next steps for Annex 48B is to clarify and remove any inconsistencies. This may require the removal of the reference to MJS and insertion of the necessary text directly in the text. This shall be further seen over the next week as the Annex is updates by myself.

  (T) For tolerance testing, add sine jitter after calibration of DJ, TJ, and amplitude. Calibration should be based on the minimum quality OUTPUT signals defined at the end of the channel. Then, since sine jitter truly represents margin for unknown external effects in real systems, then both jitter and amplitude can be degraded to worse than those minimum output signals. 
  A- This should be added to 48B.2 under calibration

  The following is the current defintion for the calibration of the receiver signal for jitter tolerance testing.

      - 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
      - Verify Rx Data Eye Vs. Receive Data Eye Mask With Sj
      - Verify Ber Of Reciever


(T) Did we include a method for deconvolving DJ from TJ? Annex A.3 in FC-PI has a 2-point method outlined, but it needs correction (I wrote that section, so I know what I screwed up). Some method for
deconvolution is probably a good idea. It does not exist cleanly anywhere in MJS.

A- Tom to send out explanatory email concerning this curve fitting point.

(T) I sent an email out recently that dealt with potential issues between jitter specs and clock frequency specs. I have to confess I haven't had time to complete my thoughts on this, but I sense there
are some holes between these 2 specs that could cause problems, at least in concept. I'll try to continue work on this if/when I ever find the time.

A- Tom to think about whether he wants to send something out.


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

2.5.2 Clause 47.4

  - Current Section For Clause 47.4 updated currently by Anthony Sanders For D3.0. See Draft Specification.  

  A- Final update of Clause 47.4 needed (see attachment at end)

  A- Make sure that Golden PLL, is not referenced, only HPF. (Allows
  for TIA).

  A- Includes reference in methodology conerning clock offsets and
  asynchronous clocks for transmit and receive paths.

  A- We need a note concerning where the data eye mask is position in the data eye!!!!!

  (T) Need horizontal (time) definitions for 0 and 1 UI for mask positioning.  Presently, the mask is centered, yet 0 and 1 are not defined. I propose that 0 and 1 be defined by the mean of the crossing
histograms. Most CDRs probably use media, which is very similar to mean in most cases and is quick and consistent. Beyond this, there may be some that would like the mask to NOT be centered. I am okay with
this, if it makes sense - it would imply an asymmetrical mask. However, I am against the ability to float the mask around as needed to clear the signal traces...
  A- This should be added to data eye part of specification, or as clarification in Annex48B
  - The mean as opposed to the median should be the easiest method.


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


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.

    - The figure shall remain the same, with the appropriate
    table. The additional table with sinusoidal jitter shall be
    included within the jitter section.



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

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 :

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

  - Crosstalking Specifications From Typical Connectors To Be
  Collected From Connector Manufacturers By Ali.
  Closed.

  - Theoritical Simulation Of Expected Differential Crosstalk To Be Done (Anthony)
  Basically have seen that crosstalk on PCB and package is nothing.... <-60dB.

  - Shelto provided Datasheets For Typical Connectors To Dawson,
  Who Will Draw Some Conclusions.

  - Dawson has sent out email concerning conclusion to information
  provided by Shelto. Some questions exist with reference to signal
  detect point raised by Joel, and also feedback from connector
  distributors.


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@Ti.Com>) 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


  - Return loss originally was intended only for receiver (10 dB
  diff, and 5 dB common mode).  It would very difficult to meet to
  meet transmit return loss.  In the IB we added Zdiff, ZSingle_Ended,
  10% matching, but not the return loss (Ali comment) 


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.

  Based on the current email traffic there still seems to be the
  opinion that it is not possible to pin down the group delay of a
  compliance channel

  (D) The compliance channel group delay spec appears "broken". 
  A- There is some work in progress toward a solution. (Note 1)


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.


4.9 AC Coupling (Email from Mike Jenkins)


  >From the teleconference this morning, I owed a response on the
  issue of AC coupling in the standard 100 ohm load, in particular,
  the pole frequency of the AC coupling.  For passing 8B/10B coded
  data, table B.1, "Fibre Channel - Methodologies for Jitter
  Specification" a ratio of pole frequency to bit rate less than about
  0.0002 produces insignificant jitter (due to the capacitor's
  non-zero impedance).  Hence, pole frequency < 0.0002*3125 MHz =
  0.625 MHz.  For my money, 1 MHz is close enough.  The smallest value
  blocking capacitors I've seen in applications is 2400 pF, which, on
  a 50 ohm line, yield a 1.326 MHz pole.  Likewise, 0.01 uF yields
  0.318 MHz.

  One other effect to consider is that (assuming the measurement is
  taken after the blocking capacitor), while the capacitor's non-zero
  impedance introduces jitter, it acts as a high-pass filter.
  Therefore it actually REDUCES the jitter created by the channel.
  Hence, the pole frequency should be restricted from being too high
  to preclude accidentally or intentionally optimistic measurements.

  In summary, I think 1 MHz is a good value, permitting use of
  reasonably valued capacitors and minimizing jitter induced by the
  coupling capacitor itself.



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

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

  - The current defined patterns are finally fully accepted as being part of the v3.0 specification.

  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.

  - Matlab Phase Model To Verify Use Of Hpf And Cjpat (Ifx)

    - Results of Matlab model can be referenced from reflector
    presentations from Infineon. These simulations currently show that
    the effect of HPF and CJPAT leads to an increase of the DJ from
    the current simulations by 65%.

    Current channel simulation are showing about 0.123UI, therefore
    with additional 1.65 from HFP effect we have 0.2UI, which agrees
    approximately with current specification.

    a- Additional 0.05UI of jitter must be found from somewhere. This
    is to be discussed in following telco. Solved see below.

  - There is voiced concern from Piers concerning the use of CJPAT as a
  compliance pattern.

    A- Must we add the DJ really together...??? We must somehow decide whether all this jitter is data dependant and correlated or not. This would allow us to use convolution, which may give as a few mUI here and there.
   A- Tom to repost information concerning effect of random jitter on effective DJ.
   A- Proposal to solve the current jitter specification. 
 	- Increase channel jitter to 0.2UI
   	- "Other" should be treated as SJ depending upon whether we are talking about compliance testing or system budget. 
	- Make "Other" 0.1UI for system budget to avoid confusion.



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

  Use Of High Pass Filtering When Assessing The Transmit Eye Should Be
  Used When Assessing Long Patterns To Account For Tracking
  Behavior. See 6.4.1.

  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.

  Measurement Results from Giga

    Some investigations from Giga (distributed on the reflector, show
    limitations of currently available DEMUXs. These results would
    initial show that the current jitter budget for the XAUI interface
    is too aggressive for the receive side. This results are based on
    SONET tolerance testing, and it is currently the opinion of IFX
    that the peak to peak sinusoidal 1dB penality, cannot be directly
    used to show the performance of the receiver, but must be first
    converted to a offset specification.

    A- Convertion of the SJ jitter from Giga into absolute time offset
    must be done (Ant)

    Ongoing,... have models runnning at the moment, and hope to have results in the coming week.

    The actions concerning results for the channel simulation can be now closed.


11. XAUI signal detect

  - See email from Joel Dedrick <Joel_Dedrick@pmc-sierra.com>
  - It is currently considered that signal detect mecanisms are
  possible. (reference to Infiniband)

  (D) The XAUI signal detect issue was unanimously resolved: There is no additional signal_detect pin or mandatory loss-of-signal detection on the XAUI. This was the only change to clause 47 in going from D2.2 to D2.3. (The D2.3 draft now available to task force members on the web site.)


12. Frequency Tolerance Measurement Methodology

  - Tom has put email out on reflector, comments moving. Issue is more
  definitional as opposed to critical


13. Electrical Specification

13.1 Amplitudes

  - In Tampa meeting we agreed the RX amplitude will be fixed to
  1600 mV and TX need to be determined.  Here you need some margin and
  as allowing some reflection.  Probably maximum TX need to be
  lowered. (comment from Ali)

  - Fig 47-4 assuming measured with an ideal load does not include 4%
  cross talk which equates to 63 mV under worst case scenario of 1600
  mV and 200 mV.  Loss allocation in the table 47-6 specifies 4.5 dB
  for others but according to eye diagram Fig 47-4 some one may
  introduce more loss.  The 4% crosstalk results in 31% additional eye
  closure with an actual XAUI receiver.  Return loss penalty
  associated with a XAUI receiver gets absorbed in to the SerDes
  effective sensitivity, but the crosstalk may not.  As the biggest
  source of the crosstalk is the connector. (additional comment from
  Ali)

  A- Thought about above comments welcome

13.2 Differential Skew

  - Differential Skew can't be measured separately from DJ even if you
  are sending 1010, you still may have DCD.  The total DJ already
  include the Diff_Skew so I would propose removing it since it can't
  be measured. (comment from Ali)

  - Similar comments made by Tord. Conclusion is to remove this from
  the specification.

  A- Comment to be entered and accepted.

13.3 Definition of ISI loss vs Other Losses

  - It seems to me the connector loss is lumped as part of
  interconnect loss resulting in 7.5 dB of loss.  Under some cases
  where the 7.5 dB is just ISI some implementation may not work.  We
  should try to separate ISI loss from connector+misc+croasstalk
  loss. (comment from Ali)

  A- Thought about above comment welcome


14. Receive Equalisation

  It should be noted again that the IEEE specificies compliance for
  transmitters with and without equalisation, but does not restrict an
  chip developer from implementing receive equalisation. However, it
  is clear depending upon the implementation the defined transmit
  jitter specification could be violated.



------------------------------------------------------------
Section 47 Attachment
------------------------------------------------------------

47.4.1 Jitter test requirements 

Terms and definitions for effective jitter and random error processes
as used by this specification are defined in Annex.48B.1 and should be
studied carefully before compliance testing is started. 


47.4.1.x Transmit Output Jitter

47.4.1.x.x Transmitter With No Implemented Equalization. 

  The output of the driver when terminated as defined in section
  47.3.3 and measured using one of the reference methods as defined in
  Annex.48B.3 shall conform to

  a) the specified transmitter deterministic and random jitter as
  defined in table 47-2, and

  b) the data eye as defined in figure 47.7 and table 47.4.

  under the conditions that 

  a) the transmission pattern is CJPAT, as defined in Annex.48A,

  ------------------------------------------------------------
  b) the extracted clock used for measurement is High Pass Filtered
  with a corner frequency of 3.125GHz / 1667 and 20dB rolloff, based
  on the theory presented in of Annex 48B.1.5, and 
  ------------------------------------------------------------

  c) all other channels in the transmit and receive direction are
  active.


47.4.1.x.x Transmitter With Implemented Equalisation

  Using one of the reference methods as defined in Annex.48B.3 both 

  a) the output of the driver when terminated as defined in section
  47.3.3 and

  b) the output of the filtered driver where the filter has a worst
  reponse than defined for the compliance channel, section
  47.3.3.5. and is terminated, as defined in section 47.3.3

  shall conform to 

  a) the specified receiver deterministic and random
  jitter as defined in table 47.5, and 

  b) the data eye as defined in figure 47.4 and table 47.3 (without
  sinusoidal jitter)

  under the conditions that 

  a) the transmission pattern is CJPAT

  ------------------------------------------------------------
  b) the extracted clock used for measurement is High Pass Filtered
  with a corner frequency of 3.125GHz / 1667 and 20dB rolloff, based
  on the theory presented in of Annex 48B.1.5, and 
  ------------------------------------------------------------

  c) all other channels in the transmit and receive direction are
  active and terminated with valid data. (Clocks are not synchronised.)


47.4.1.x Receiver Tolerance Testing

  Using one the reference methods defined in Annex.48B.2 the receiver
  shall tolerate the specified deterministic and random jitter as
  defined in table 47.5 given the additionally applied sinusoidal
  jitter mask, section 47.3.4.4., for all frequencies, under the
  conditions that

  ------------------------------------------------------------
  a) a stressed signal with data eye opening amplitude equal to
  receiver sensitivity, defined in 47-4, but conforming to the data
  eye defined in 47.4, generated given the reference method defined in
  Annex 48.B.4. is used
  ------------------------------------------------------------

  b) all other channels in the transmit and receive direction are
  active. Include clock offset

  c) the received pattern is CJPAT


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