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.