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

Re: Fwd: XAUI Jitter Protocols for Plenary March 2001



i'm not certain i read this correctly, but it seems there are a couple of problems
with this message:

i didn't find any attachments, though there is quite a lot of text in the message.  was
something dropped?

the link to the web site has mixed case, which leads nowhere in Netscape.  if i set all
characters to lower case, the link works.
--
jmw

At 06:33 AM 15-03-01 -0800, Anthony Sanders <anthony.sanders@infineon.com wrote:

>X-Envelope-Sender-Is: anthony.sanders@infineon.com (at relayer goliath.siemens.de)
>Date: Wed, 14 Mar 2001 16:54:25 +0100
>From: Anthony Sanders <anthony.sanders@infineon.com>
>Reply-To: anthony.sanders@infineon.com
>Organization: Infineon Technologies
>X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686)
>X-Accept-Language: en
>To: "Serial PMD reflector (E-mail)" <stds-802-3-hssg-serialpmd@ieee.org>
>Subject: XAUI Jitter Protocols for Plenary March 2001
>Sender: owner-stds-802-3-hssg-serialpmd@ieee.org
>X-Resent-To: Multiple Recipients <stds-802-3-hssg-serialpmd@majordomo.ieee.org>
>X-Info: [Un]Subscribe requests to  majordomo@majordomo.ieee.org
>X-Moderator-Address: stds-802-3-hssg-serialpmd-approval@majordomo.ieee.org
>
>Please find attached Protocols for
>
>1) XAUI Jitter 13th March 2001
>2) XAUI Jitter 14th March 2001
>
>plus
>
>1) Updated XAUI Jitter Issue List
>
>
>Anthony Sanders
>Principal Engineer
>Infineon Technologies
>Munich Germany.XAUI Jitter Adhoc Protocol
>13th March 2001
>8am..10:30am
>
>(Please refer to Reflector IFX Presentation Foils for individual pdfs
>referenced).
>
>Chair :
>Anthony Sanders, Infineon Technologies
>
>Attendants :
>Thomas Dineen , Netcom
>Robbie Shergill, National Semiconductor
>Bjoern Rudberg, Optillion
>Kolchrio Mashiko, Mitsubishi Elec.
>Justin Gaither, Xilinx
>June Roemer, Optillion
>Eric Lynskey, UNH-IOL
>Tom Gray, Tality
>Narayanan Raman, LSI Logic
>Schelto van Doorn, Intel
>............................................................
>
>Agenda for next few days :
>
>  Comment resolution
>
>  Get consensus of current ideas and concepts. "Is there something
>  missing?"
>
>  See email from Dawson concerning breakdown for next few days
>
>............................................................
>
>Agenda For This Morning :
>
>- Introduction
>- Status
>- Recap Methodology
>- Current Jitter Specification
>- Transmitter Specification
>- Channel Simulations
>- Receiver Tolerance
>
>............................................................
>
>XAUI Jitter Status :
>
>  Weekly Telco Wednesday 10:30 PST, with around 8..10 experienced
>  attendants

>  XAUI Jitter Issues Document (All open issues entered as comment)
>
>  Measured Channel Model giving S21 polynomial
>
>  Stable Proposed Methodology based on HPF and CJPAT (Section 47.4.1,
>  Annex 48A/B)
>
>  Stable Jitter Budget and Channel Model proven by Mixed Frequency
>  Pattern Simulation with reasonable JT_Tx, and aggressive but
>  acceptable JT_Rx.
>
>  Current MATLAB simulation proceeding concerning HPF and CJPAT
>
>  Theoretical Analysis of "Actual Receiver Phase Offset" based on 1dB
>  Reciever Penality Measurements.
>  ............................................................
>
>Methodology (Recap) :
>
>  Reference to Annex 48A, 48B, and Section 47.4.1. See current XAUI
>  Jitter Issue List for current proposed 48B and 47.4.1
>
>  Current methodology is for long complex patterns (CJPAT) with HPF
>  Golden PLL; necessary for elimination of vLF filter.
>
>  Use of HPF Golden PLL in combination with CJPAT, gives rise to
>  increased amounts of DJ due to the tracking behavior of the PLL. It
>  is currently questionable as to how to relate the currrent
>  simulation results for a Mixed Frequency Pattern for the Channel
>  Compliance.
>
>  Current Simulation Model for analysis of HPF and CJPAT
>
>    - Model Description (block.pdf)
>
>    - The FIR in the model converts the data train into amplitude
>    samples
>
>    - DDJ is generated by attenuation of the signal, and the
>    corresponding crossover point given this amplitude; the model
>    contains an amplitude to jitter conversion. (A2T.pdf, AvsT.pdf)
>
>    - Simulation result with and without HPF (Sim.pdf)
>
>............................................................
>
>Current Jitter Specification :
>
>  See current specification D2.2
>
>............................................................
>
>Transmit Jitter :
>
>  Current specification would seem reasonable, but should not be
>  tightened.
>
>............................................................
>
>Current Channel Simulations :
>
>  Simulations of channel show wc jitter that can be introduced by the
>  channel. See simulation results from reflector (from IFX, Intel &
>  Mysticom)
>
>  a- Questions still exist as to whether these simulation results are
>  correct. The channel shows the peak to peak jitter with respect to a
>  fixed non-tracking PLL. With a real PLL, the PLL will tend to track
>  out low frequency jitter, but be more sensitive to sharp changes in
>  transistion density.  See Section 6.4.1.
>
>............................................................
>
>Jitter Tolerance :
>
>  There is a large difference between 1dB receiver penality, and time
>  jitter. This can be seen in (DJ.fig).
>
>  1dB receiver penality should be calculated using theoritical
>  background summaried in (Test.pdf)
>
>  This gives rise to Offset to BER results (xOffset.pdf)
>   
>  Results from Giga can be downloaded from Reflector. It is currently
>  the opinion of this adhoc that the results should be carefully
>  understood for how the applied SJ jitter giving the 1dB receiver
>  penality translates into receiver offset.
>
>  a- Convertion of the SJ jitter from Giga into absolute time offset
>  must be done (Ant)
>
>............................................................
>
>
>XAUI Jitter Adhoc
>14th March 2001
>17:00 - 19:45
>
>(Please refer to Reflector IFX Presentation Foils for individual pdfs
>referenced).
>
>Chair :
>Anthony Sanders, Infineon Technologies
>
>Attendants :
>
>
>............................................................
>
>Agenda
>
>- Recap Methodology
>- Current Jitter Specification
>- Transmitter Specification
>- Channel Simulations
>- Receiver Tolerance
>
>............................................................
>
>Methodology (Recap) :
>
>  Reference to Annex 48A, 48B, and Section 47.4.1. See current XAUI
>  Jitter Issue List for current proposed 48B and 47.4.1
>
>  Current methodology is for long complex patterns (CJPAT) with HPF
>  Golden PLL; necessary for elimination of vLF filter.
>
>  a- Make sure that Golden PLL, is not referenced, only HPF. (Allows
>  for TIA).
>
>  Use of HPF Golden PLL in combination with CJPAT, gives rise to
>  increased amounts of DJ due to the tracking behavior of the PLL. It
>  is currently questionable as to how to relate the currrent
>  simulation results for a Mixed Frequency Pattern for the Channel
>  Compliance.
>
>  Current Simulation Model
>
>    - Model Description (block.pdf)
>
>    - The FIR in the model converts the data train into amplitude
>    samples
>
>    - DDJ is generated by attenuation of the signal, and the
>    corresponding crossover point given this amplitude; the model
>    contains an amplitude to jitter conversion. (A2T.pdf, AvsT.pdf)
>
>    - Simulation result with and without HPF (Sim.pdf)
>
>    - Simulations results for Mixed Frequency Pattern and
>    CJPAT. (Sim2.pdf)
>
>............................................................
>
>Current Jitter Specification :
>
>  See current specification D2.2
>
>............................................................
>
>Transmit Jitter :
>
>  Current specification would seem reasonable, but should not be
>  tightened.
>
>............................................................
>
>Current Channel Simulations :
>
>  Simulations of channel show wc jitter that can be introduced by the
>  channel. See simulation results from reflector (from IFX, Intel &
>  Mysticom)
>
>  a- Questions still exist as to whether these simulation results are
>  correct. The channel shows the peak to peak jitter with respect to a
>  fixed non-tracking PLL. With a real PLL, the PLL will tend to track
>  out low frequency jitter, but be more sensitive to sharp changes in
>  transistion density.  See Section 6.4.1.
>
>  No but 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- Where do we get this jitter from. To be discussed in Telco.
>
>............................................................
>
>Jitter Tolerance :
>
>  There is a large difference between 1dB receiver penality, and time
>  jitter. This can be seen in (DJ.fig).
>
>  1dB receiver penality should be calculated using theoritical
>  background summaried in (Test.pdf)
>
>  This gives rise to Offset to BER results (xOffset.pdf)
>   
>  Results from Giga can be downloaded from Reflector. It is currently
>  the opinion of this adhoc that the results should be carefully
>  understood for how the applied SJ jitter giving the 1dB receiver
>  penality translates into receiver offset.
>
>  a- Convertion of the SJ jitter from Giga into absolute time offset
>  must be done (Ant)
>
>............................................................
>
>  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!!!!!
>
>............................................................
>
>
>
>Xaui Jitter Issue List
>
>14th March 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)
>
>  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
>
>
>
>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
>    - Outline sent to Dawson for inclusion in D2.2
>    - 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).
>
>
>------------------------------------------------------------
>
>Annex 48.B
>
>This annex specifies the definitions, measurement requirements, and
>allowed values of jitter for PMDs associated with the 10GBASE-X PHY
>described in Clause 48 to test its attached PMD. These measurement
>methods and specifications are intended to be used for jitter and
>wander compliance testing. The jitter test methodologies specified in
>this annex are applicable to the 10GBASE-LX4 PHY and the XAUI.
>
>48B.1 Bit Error Rate vs. Jitter Model
>
>  48B.1.1 Description of Mathematical Model
>  48B.1.2 Random Jitter
>  48B.1.3 Addition of Deterministic Jitter
>  48B.1.4 Definition of Effective Deterministic Jitter
>  48B.1.5 Effects of HPF and CJPAT on Determinsitic Jitter
>
>48B.2 Jitter Tolerance Test Methodologies
>
>  48B.2.1 Calibration of a Signal Source using the BERT Scan Technique
>  48B.2.2 Calibration of a Signal Source Amplitude
>  48B.2.3 Sinusoidal Jitter Modulation
>  48B.2.4 Direct Time Synthesis
>
>48B.3 Jitter Output Test Methodologies
>
>  48B.3.1 Jitter Output Test Methodologies
>
>  48B.3.2 Time Domain Measurement - Scope and BERT Scan
>    48B.3.2.1 Overview
>    48B.3.2.2 Golden PLL
>    48B.3.2.3 Time Domain Scope Measurement
>    48B.3.2.4 BERT Scan
>
>  48B.3.3 Time Interval Analysis
>    48B.3.3.1 Introduction
>    48B.3.3.2 Clock-less  Jitter Measurement
>    48B.3.3.3 TIA Data Reduction Procedure
>    48B.3.3.4 Total Jitter Calculation
>    48B.3.3.5 Power Density Spectrum of Jitter
>    48B.3.3.6 Data Dependent (ISI) Jitter Measurement
>    48B.3.3.7 Jitter Measurements with a "Pattern Marker and known pattern"
>    48B.3.3.8 Jitter Measurement Using a Sampling Oscilloscope (DDJ and PWD)
>
>  48B.3.4 Frequency Domain Measurement (Spectrum Analyzer)
>
>------------------------------------------------------------
>
>2.5.2 Clause 47
>
>  - Section For Clause 47 Written By Anthony Sanders For D2.1. See
>  Draft Specification. 
>
>  - Minimal update for D2.2 written. Proposal final update included
>  below.
>
>  A- Final update of Clause 47 needed
>
>  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!!!!!
>
>------------------------------------------------------------
>
>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
>
>
>------------------------------------------------------------ 
>
>
>
>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.
>
>    - 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 ???? Do we want to do this????
>      - Verify Rx Data Eye Vs. Receive Data Eye Mask With Sj
>      - Verify Ber Of Reciever
>
>
>------------------------------------------------------------
>
>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.
>
>  A- Crosstalking Specifications From Typical Connectors To Be
>  Collected From Connector Manufacturers By Ali.
>
>  A- Theoritical Simulation Of Expected Differential Crosstalk To Be
>  Done (Anthony)
>
>  - 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
>
>
>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
>
>  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.
>
>
>  - There is voiced concern from Piers concerning the use of CJPAT as a
>  compliance pattern.
>
>    A- Anthony to send email to Piers concerning compliance pattern
>    strategy.
>

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