XAUI Jitter Telco Agenda 18th April 2001
Dear XAUI Jitter Telco'ers,
Same agenda as last week.
1- Today's telco should concerntrate on initially making sure that we are consistent with all the issues that were closed in Hilton Head, and which are still to be dealt with and reentered as comments for the next ballot. (approx 1/2hour)
2- Discussion of major open electrical issues for XAUI (approx 1/2hour), e.g Group delay, electrical levels, ......
3- Lastly, if we have time, we should spend some time again agreeing upon what we discussed last week concerning the allocation of the additional channel jitter and the slight change in dealing with SJ and "Other" jitter in the system budget.
Please find attached summary of open issues extracted from the current XAUI Jitter Issue List, also attached.
Thanks for your participation and again please email me before hand if your name is not on the participation list.
Anthony Sanders
Principal Engineer
Infineon Technologies
Time : 9:30am (PDT), 18:30 (CET)
Toll free number (inside US) : 800 891 9585
International number : 865 525 3200
Participant Code : 674870
Time : 90mins
Ports : 15
<<Attendant_18Apr01.txt>>
<<XAUI_Jitter_Agenda_18Apr01.txt>>
<<XAUI_Jitter_Issues_10Apr01.txt>>
Anthony.sanders@xxxxxxxxxxxx <anthony.sanders@xxxxxxxxxxxx>,
Adam Healey <ahealey@xxxxxxxxxx>,
Bijit Patel <bijit_patel@xxxxxxxxxxxxxx>,
Bob Smith <robert@xxxxxxxxxxxxxx>,
Dennis Petrich <dpetrich@xxxxxxxxxxxxx>,
Jeff Cain <jcain@xxxxxxxxx>,
Jim Hesson <jhesson@xxxxxxxxxxxxxx>,
John Wright <john.wright@xxxxxxxxx>,
Peter Dartnell <dartnell@xxxxxxxxxxxxxxxxxx>,
Richard Dugan <richard_dugan@xxxxxxxxxxx>,
Ron Miller <rmiller@xxxxxxxxxxx>,
Shawn Rogers <s-rogers@xxxxxx>,
Leo Wong <lwong@xxxxxxxxxxxxxxx>,
Jason Chen <jchen@xxxxxxxxxxxxxxx>,
Allan Liu <allan_liu@xxxxxxxxxxx>,
"Ishwar Hosagrahar" <ishwarh@xxxxxx>,
Joel Dedrick <Joel_Dedrick@xxxxxxxxxxxxxx>,
Farzin Firoozmand <Farzin_Firoozmand@xxxxxxxxxxxxxx>
Frank Barber <Frank_Barber@xxxxxxxxxxxxxx>,
Doug.Day@xxxxxxxxxxxxxxxx,
Ali Ghiasi <aghiasi@xxxxxxxxxxxxx>,
Robbie Shergill <robbie.shergill@xxxxxxx>,
Kesling Dawson W <dawson.w.kesling@xxxxxxxxx>,
Schelto vanDoorn <schelto@xxxxxxx>,
Rich Taborek <rtaborek@xxxxxxxxxxx>,
Tom Gray <tgray@xxxxxxxxxx>
Mike Jenkins <jenkins@xxxxxxxx>,
"John Wright" <John.Wright@xxxxxxxxx>
Michael Debie <MDebie@xxxxxxxxxxxxxxxxx>,
Jeff Porter <j.porter@xxxxxxxxxxxx>,
jmw(Mike) <jmw@xxxxxxxxxxx>
Tord Haulin <tord.haulin@xxxxxxxxxxxxx>,
Tom Lindsay <Tom.Lindsay@xxxxxxxxx>
john.dambrosia@xxxxxxxxxxxxxxxxxxx
0. Current Comments To D2.1
A- summary of the classification shall be sent by Dawson to the
reflector when appropriate.
1.1 Break Frequencies And Amplitudes
A- Find Fc White Paper On Investigation Leading To Swag Number Of
0.1ui And 1.5ui For Amplitudes. (Allan) This Action Point Shall Be
Closed Upon Studying Of The Bell Labs Document.
1.2 Very Low Frequency Jitter Definition Frequency And Amplitude
A- Comment To Be Entered
2.5.1 Annex 48b
A- Arrange tutorial (Ant)
A- Updates to Annex 48b required (see Jitter Issues for more information)
A- Tom to send out explanatory email concerning this curve fitting point.
A- Tom to think about whether he wants to send something out.
2.5.2 Clause 47.4
A- Final update of Clause 47.4 needed (see attachment at end)
A- Make sure that Golden PLL, is not referenced, only HPF. (Allows for TIA).
A- Includes reference in methodology conerning clock offsets and asynchronous clocks for transmit and receive paths.
A- We need a note concerning where the data eye mask is position in the data eye!!!!!
A- This should be added to data eye part of specification, or as clarification in Annex48B
2.5.3 Termination Section
A- Comment To Be Entered
2.5.4 Receive Compliance Data Eye
A- Receive Eye Needs To Be Shown With And Without Sinusoidal Jitter.
3.2 Transmit Jitter
A- Comment To Be Entered
3.3 Random Jitter
A- Comment To Be Entered
4.3 Dj From Channel Compliance
A- Jitter Group Must Decide Whether To Accept Min/Max Channel
Compliance, And New Jitter Numbers. (See Complete Model)
4.6 Return Loss
A- ("Ishwar Hosagrahar" <Ishwarh@xxxxxx>) To Take Over Action Of
Providing Nformation Concerning This Requirement.
A- Proposal To Be Entered For Transmit And For Receiver
- 10db <= Baud/2, 8db > Baud/2
4.7 Group Delay Of Channel
A- Comment To Be Entered That Group Delay Definition To Be Removed And A Minimum Dj Should Be Defined That Must Be Induced By The Channel, For A Given Pattern, And Transmit Waveform.
A- There is some work in progress toward a solution. (Note 1)
4.8 S11 For Channel Definition
A- Comment Should Be Entered, Exact Numbers To Be Set In Next Telco.
6.4.1 Compliance Definition
A- Must we add the DJ really together...??? We must somehow decide whether all this jitter is data dependant and correlated or not. This would allow us to use convolution, which may give as a few mUI here and there.
A- Tom to repost information concerning effect of random jitter on effective DJ.
A- Proposal to solve the current jitter specification.
- Increase channel jitter to 0.2UI
- "Other" should be treated as SJ depending upon whether we are talking about compliance testing or system budget.
- Make "Other" 0.1UI for system budget to avoid confusion.
10. Overall Verification Of Jitter Budget
A- Convertion of the SJ jitter from Giga into absolute time offset must be done (Ant)
13.1 Amplitudes
A- Thought about above comments welcome
13.2 Differential Skew
A- Comment to be entered and accepted.
13.3 Definition of ISI loss vs Other Losses
A- Thought about above comment welcome
Xaui Jitter Issue List
10th April 2001
Goals Of Adhoc :
1. Define Jitter Mask For Transmitter.
2. Jitter Measurement Methodology Golden Pll Or Tia.
3. Jitter Penalty Of Channel. The Pattern K28.5+/- Is Sufficent
Pattern To Test The Channel, Since K28.5 Has 101 Transition As Well 5
Consecutive Ones Or Zeros.
4. Jitter Tolerance For Component Is Well Established, But For Systems
Difficult To Implement And Beyond The Scope Of This Group. We Will
Define The Basic Jitter Tolerance Testing Requirement And Jitter
Patterns.
5. Jitter Compliance For Pre-Emphasis Driver With Golden Pcb. Would
Be Sufficient For A Pre-Emphasis Driver To Just Meet The Jitter
Specification Of Receiver At 0" And At 20" With Golden Pcb?
6. Pattern For Compliance For Example K28.5+/-, Fc Cjtpat, Or Fc
Crpat.
Contents :
0. Comments For D2.1
1. Jitter Tolerance Mask
1.1 Break Frequencies And Amplitudes
1.2 Very Low Frequency Jitter Definition Frequency And Amplitude
1.3 Receiver J
2. Jitter Measurement Methodology
2.1 Termination Methodology
2.2 Fc Definitions For Methodology. (Contribution By Tom Lindsay)
2.2.1. Jitter Definitions
2.2.2. Signal Integrity For Testing
2.3 Manufactures Standard Test Definition
2.4 Jitter Compliance Equipment
2.5 Section And Annex
2.5.1 Annex 48b
2.5.2 Clause 47
2.5.3 Termination Section
2.5.4 Receive Compliance Data Eye
3. Transmit Jitter
3.1 Transmit Data Eye X1, X2 (Difference)
3.2 Transmit Jitter
3.3 Random Jitter
4. Additional Jitter Budget
4.1 .....
4.2 Buj (Boundied Uncorrelated Jitter)
4.3 Dj From Channel Compliance
4.4 Fext/Next (Cross Talk)
4.5 Connectors & Vias (Current Budget Probably Not Enough)
4.6 Return Loss
5. Equalised Compliance Testing
6. Compliance Patterns
6.1 Jitter Strategy
6.1.1 Purpose Of Jitter Test Patterns:
6.1.2 Test Equipment Limitations
6.1.2.1 Pattern Generation For Receiver Test:
6.1.2.2 Xaui Transmitter Jitter Measurement:
6.1.3 Pattern Types
6.1.4 Summary:
6.2 Basis Of Fc Jitter Pattern (Contribution From Tom Lindsay)
6.2.1 Purpose/Background
6.2.2 Pattern Content
6.2.3 Pattern Lengths
6.2.4 Other Notes
6.3 Random Jitter Measurement Of K28.7
6.4 Defined Patterns
6.4.1 Compliance Definition
6.4.1.1 Background For Cjpat And Hpf For Compliance (Tom Lindsay)
6.5 Test Equipment For Pattern Compliance Testing
7. Ber Definition
8. Instantaneous Bit Shift
9. Sonet Sj
10. Overall Verification Of Jitter Budget
------------------------------------------------------------
0. Current Comments To D2.1
- Only comments concerning technical completness shall be accepted
for Plenary. The author of the comment, shall be asked to defer his
comment until the next ballot session, in May.
- Therefore there will be 3 classes of comments. (Reject, reject
until next plenary, accept for this plenary)
(D) The draft standard was unanimously approved for 802.3 Working Group ballot. This indicates that the attendees believed the draft is "technically complete", meaning that further technical refinements are anticipated but there are no known technical holes r insurmountable barriers. W.G. ballot is scheduled to begin on April 6 and end May 11.
A- summary of the classification shall be sent by Dawson to the
reflector when appropriate.
------------------------------------------------------------
1. Jitter Tolerance Mask
1.1 Break Frequencies And Amplitudes
F_C / 1667, And F_C / 25000 Corner Frequencies Are Still
Open. Agilent Shall Make More Comments To The Reflector And Also
Raise A Comment To The Specification Concerning This Issue. However,
It Would Seem The Majority Are Still In Favor Of Keeping The
Frequencies As Current Proposed By Ali. This Issue Remains Open.
Allan Has Researched In Some Detail Where The Current Corner
Frequencies And Amplitude Come From, But Has Currently Not Being
Able To Pin Anything Down.
There Appears To Be A Frequently Referenced Document "Bell Labs
Technical Report (´92)" That Allan Is Trying To Aquire. Dawson
Suggested That Allan Also Contact Adam Healy.
A- Find Fc White Paper On Investigation Leading To Swag Number Of
0.1ui And 1.5ui For Amplitudes. (Allan) This Action Point Shall Be
Closed Upon Studying Of The Bell Labs Document.
An Upper Frequency Limit Of The Jitter Tolerance, Was Suggested By
Mysticom. However, After Discussion It Is Clear That There Is Some
Confusion Within The Fiber Channel Specification, And The 5mhz Is
Only A Pratical Limit. The Jitter Tolerance Of 0.1ui Should Extend
Up To Infinity.
Movement Of The Upper Frequency Limit Break For The Jitter Tolerance
Recieved No Support In La (Jan).
Proposal To Limit Upper Limit Of Sj To 20mhz, Due To Limitations In
Measurement Equipment Was Accepted By La (Jan) Group.
1.2 Very Low Frequency Jitter Definition Frequency And Amplitude
- Basic Fundimentals Of Fifo Calculations For Low Frequency Jitter
Available From Shelto.
Http://Grouper.Ieee.Org/Groups/802/3/Ae/Public/Adhoc/
Serial_Pmd/Jitter_Documents/2clocks.Pdf
- Extend Down To 22khz, With 20db/Dec, And Then Cap Down To Dc,
Agreed By Telco.
A- Comment To Be Entered
The sinuosoidal jitter that is currently defined for Jitter Tolerance, is capable of generating phase offset between channels that are greater than the demultiplexed 10b word boundary. This test however, is implementation and shall not be discussed anymore in this adhoc.
1.3 Receiver J
- Current Tj=0.65ui, Dj=0.41ui
- 0.41ui Is Really Limits For Serdes Design. (Comment From Hari
Working Group, Ali)
- Concerns From Ali, And Eyan State That Receive Dj Of 0.41ui Plus
The Jitter Tolerance Of 0.1ui For High Frequency Will Give A Total
Dj Of 0.51ui Which Is Too High. This Point Must Be Discussed This
Week.
Proposal To Reduce Recieve Dj To 0,36 And Tj To 0.6 Accepted By La
(Jan) Group. This Then Allow For The Additional 0.1ui Of Sj During
Testing.
------------------------------------------------------------
2. Jitter Measurement Methodology
2.1 Termination Methodology
- Only Dut And Measurement Equipment, No Tap Adaption Not Required.!
- Conversion From 150 To 100, Not Required, Only Ever 100
- Ac Coupling Is Standard Therefore Need To Define Ac Coupling
Capacitance And Termination Resistor Values And Tolerance.
- Only Have Balanced Signals, Therefore Methods Defined For Balance
To Unbalanced Signals Should Be Adopted, But Of Course With 100ohm.
2.2 Fc Definitions For Methodology. (Contribution By Tom Lindsay)
In The 12/20 Conference Call, I Noted Two Important Conclusions
Within Fibre Channel That Have Followed Publication Of The Mjs
Technical Report (99-151v2):
2.2.1. Jitter Definitions
That Simple Pk-Pk Is Unsufficient As The Requirement For Dj; That An
Overall Weighting Function That Captures Not Only The Pk-Pk But The
Shape Of The Density Function Is Required For Dj; That This May Be
Known As "Effective Dj" And That It (And "Effective Rj") Are
Determined Or Derived From The Bathtub Curve. Curve Fit Methods Have
Been Suggested (See 99-489v0 And 99-488v0, And Annex A.3 In Revision
10 Of Fc-Pi (00-645v0)).
99-464v0 Discusses This Issue By Comparing Pk-Pk Dj Specification
Vs. Effective Dj Specification. Note: In 99-464v0, Effective Dj Is
Proposed/Based On A Dual-Delta Function (See Annex A Of The Mjs
Technical Report). This Can Be Thought Of As Square Wave Or
Bang-Bang Jitter. 99-464v0 Uses Dcd (Duty Cycle Distortion) As An
Example Of Square Wave Jitter.
Pages 12 & 13 Provide The Conclusions Of 99-464v0.
Also See Figure C.1 In The Mjs Technical Report.
2.2.2. Signal Integrity For Testing
That Tolerance Testing Should Include Not Only Jitter But Also At
Least Amplitude And Rise/Fall Time Settings. Figure C.2 In The Mjs
Report Only Induces Jitter - Amplitude And Rise/Fall Times Are Not
Specified, But The Implication From Figure C.2 Is That The Test
Signals Are Directly Transmitted From A Limiting Amplifier.
99-618v0 Attempts To Address This Issue. In Particular, Refer To
Pages 2, 4, 8, & 20.
Page 8 Shows A Recommended Test Configuration That Imposes
Simultaneous Jitter, Slow Rise/Fall Times, And Amplitude
Closure. Also,
- The Sine Wave Frequency Must Sweep To Well Above The Corner
Frequency Of Available Cdr Circuits.
- Depending On Its Internal Functioning, A Limiting Amplifier May Be
Required Ahead Of The Pattern Generator.
- The Random Noise Generator Spectrum May Want To Be Wider For The
Xaui Rate.
Page 20 Notes That Sine Jitter (Sj) Is Added To The Tolerance Signal
After The Other Jitter, Amplitude, And Rise/Fall Time
Characteristics Are Calibrated. This Additional Jitter Term Not Only
Adds Jitter But Further Reduces The Amplitude Opening. This Effect
Has Been Since Captured In Fc-Pi (See 00-645v0, Figure 34).
Page 20 Also Notes That Jitter (Dj/Rj) Is Calibrated Using The
High-Pass-Filter (Hpf) Function (I.E., Dr/1667) And Using The
Effective Jitter Concept Discussed Above. Note - High-Pass Filtering
And Effective Jitter Are Required For All Jitter Measurements,
Whether For Output Compliance Testing Of Tolerance Calibration
(Except Sj). See Pages 13 & 14 Of 99-618v0 For Examples Of The
Application Of The The Hpf And Effective Jitter (Shown As "Curve
Fit").
2.3 Manufactures Standard Test Definition
The Question Of Whether The Compliance Testing Method Should This Be
Beter Defined By Chip Designers And Possibly Entered In A
Specification Or White Paper, Did Not Gain Favor.
The Issue Of Specification Of Operating Conditions Was Raised By
Optillion, However It Is The Pratice Of Ieee Specification Not To
Define Any Environmental Conditions. These Issues Should Be Covered
By The Pics Performers.
2.4 Jitter Compliance Equipment
Note From Ron Miller Referring To Possible Equipment That Can Be
Used For Jitter Measurement.
Mainframes Needed:
86100a Dca
Or 83480a Dca
Clock Recovery Modules:
83491 2.5 Gbs Electrical Clock Recovery Module
Or 83492a 2.5 Gbs Multimode Clock Recovery Module.
?- Questions Exist From Ali Concerning Whether These Device Will
Under Estimate Jitter Due To Bandlimiting Effects.
2.5 Ieee Sections, Annex´S And References
2.5.1 Annex 48b
- It Has Been Decided That Clause 47 And 48 Shall Not Reference The
99-151v2 For Methodology Due To
- It´S Status As An International Standard
- The Need For Clarification Of Many Jitter Terminology
- Large Majority Of Document Is Directed At Fc
- References For Methodology Would Be Manditory
- Annex 48a Shall Continue To Reference 99-151v2 As Merely An
Historical Reference Showing The Basis For The Calculation Of The
Various Patterns.
Current Annex 48B was written in the Hilton Head Plenary by a breakout team.
(D) The XAUI jitter methodology was discussed in detail and given a vote of confidence. Annex 48B was approved describing this methodology. (Presentation or clarifications needed.)
The adhoc is of the opinion that due to the complexity of jitter and the current implications of the jitter methodology that is being defined, a Tutorial on jitter at the next available date would be advantageous in eduating both the commitee and help bring the current proposals to final specification. Michael Debie from Wavecrest volunteed equipment that could be made available for also demonstrated the methods described.
A- Arrange tutorial (Ant)
Main next steps for Annex 48B is to clarify and remove any inconsistencies. This may require the removal of the reference to MJS and insertion of the necessary text directly in the text. This shall be further seen over the next week as the Annex is updates by myself.
(T) For tolerance testing, add sine jitter after calibration of DJ, TJ, and amplitude. Calibration should be based on the minimum quality OUTPUT signals defined at the end of the channel. Then, since sine jitter truly represents margin for unknown external effects in real systems, then both jitter and amplitude can be degraded to worse than those minimum output signals.
A- This should be added to 48B.2 under calibration
The following is the current defintion for the calibration of the receiver signal for jitter tolerance testing.
- Set 200ppm Offset Between Transmit And Receive Clock
- Enable All Channels In Transmit And Receive Direction
- Using Cjpat
- Transmitter + Dj + Rj -> Channel -> Rx Data Eye
- Calibrate Dj And Rj Of Rx Data Eye To Confirm To Specified
Receive Jitter
- Adjust Output Level Of Pattern Generator Such That Eye
Amplitude = Channel Rx Eye
- Verify Rx Data Eye Vs. Receive Data Eye Mask Without Sj
- Add Specified Sj For Given Frequency
- Verify Rx Data Eye Vs. Receive Data Eye Mask With Sj
- Verify Ber Of Reciever
(T) Did we include a method for deconvolving DJ from TJ? Annex A.3 in FC-PI has a 2-point method outlined, but it needs correction (I wrote that section, so I know what I screwed up). Some method for
deconvolution is probably a good idea. It does not exist cleanly anywhere in MJS.
A- Tom to send out explanatory email concerning this curve fitting point.
(T) I sent an email out recently that dealt with potential issues between jitter specs and clock frequency specs. I have to confess I haven't had time to complete my thoughts on this, but I sense there
are some holes between these 2 specs that could cause problems, at least in concept. I'll try to continue work on this if/when I ever find the time.
A- Tom to think about whether he wants to send something out.
------------------------------------------------------------
2.5.2 Clause 47.4
- Current Section For Clause 47.4 updated currently by Anthony Sanders For D3.0. See Draft Specification.
A- Final update of Clause 47.4 needed (see attachment at end)
A- Make sure that Golden PLL, is not referenced, only HPF. (Allows
for TIA).
A- Includes reference in methodology conerning clock offsets and
asynchronous clocks for transmit and receive paths.
A- We need a note concerning where the data eye mask is position in the data eye!!!!!
(T) Need horizontal (time) definitions for 0 and 1 UI for mask positioning. Presently, the mask is centered, yet 0 and 1 are not defined. I propose that 0 and 1 be defined by the mean of the crossing
histograms. Most CDRs probably use media, which is very similar to mean in most cases and is quick and consistent. Beyond this, there may be some that would like the mask to NOT be centered. I am okay with
this, if it makes sense - it would imply an asymmetrical mask. However, I am against the ability to float the mask around as needed to clear the signal traces...
A- This should be added to data eye part of specification, or as clarification in Annex48B
- The mean as opposed to the median should be the easiest method.
------------------------------------------------------------
2.5.3 Termination Section
A- Comment To Be Entered
- Termination For Measurement Of Jitter Shall Refer To 47.3.3 Driver
Characteristics, Which Must Be Updated To Include Tolerance Of +/-5%
2.5.4 Receive Compliance Data Eye
A- Receive Eye Needs To Be Shown With And Without Sinusoidal Jitter.
- The figure shall remain the same, with the appropriate
table. The additional table with sinusoidal jitter shall be
included within the jitter section.
------------------------------------------------------------
3. Transmit Jitter
3.1 Transmit Data Eye X1, X2 (Difference)
Currently Specification Is Wrong,
Defined Is X1=0.175ui, X2=0.415ui (Aligent)
Proposal From Ali, X1=0.175ui, X2=0.365ui
Comment From Mike, X1=0.175ui, X2=0.380ui
La Proposal, X1=0.175ui, X2=?
A=400mv, B=800mv
X2 Is Based Upon Assumptions Of Certain Rise And Fall
Times. Agilent Performed Initial Investigation Based On A Simple
Trapazoidal, With Additive Noise. Ali Proposal Is More Based Upon
Realistic Waveforms With Rounded Corners. Agilent Would Have No
Objections To New X2 Numbers.
Mike Jenkins Completed Investigation Of Basis For X1, X2 Values.
Please Refer To Reflector For Details.
3.2 Transmit Jitter
Currently Defined Dj 0.17ui, Tj 0.35ui
P- Proposal From Infineon To Wait Until Xaui Compliance Channel Is
Defined To Allow Jitter Budget To Be Completed.
!- Ongoing Concern From Ali And Eyad Concerning Total Jitter
Tolerance (See Emails).
- Allan Sent The Pwl Input Waveform Used For The Agilent Simulations
To Anthony To Enable Analysis Of The Current Compliance Channel
S21. (04jan00 Data From Allan Received)
Proposal La (Jan), And General Opinion. Current Jitter Specification
Is Hard Already And Should Be Left As Is.
- Deterministic Jitter For Transmitter Should Be Specified And Not
Only Informative. This Should Include A Comment Concerning
Transmitter With Equalisation Having To Comply To Receive Jitter
Requirements.
A- Comment To Be Entered
3.3 Random Jitter
A- Comment To Be Entered
Transmit Rj Not To Be Bandlimited.
Normative Definition Of Rj :
Received Random Jitter Is Defined As Being Above 20mhz With A
20db/Dec Rolloff At Lower Frequency. It Should Be Noted That The
Random Jitter Is Naturally Bandlimited At Higher Frequency By The
Sampling Nature Of The Data.
------------------------------------------------------------
4. Additional Jitter Budget
4.1 .....
4.2 Buj (Boundied Uncorrelated Jitter)
This Noise Source Is Covered By Sj Margin.
4.3 Dj From Channel Compliance
- Data From Ali (Without Connectors And For 16") Shows Measured Data
Eye For 2.5gbps And 3.2gbps. However, S21 Transfer Data Is A Little
More Optimistic In Comparison To The Current Available Data From The
Compliance Group. 2.5g Data Eye Show 0.1ui Dj, And For 3.125g Approx
0.11ui. Confirming The Current Numbers In The 802.3 Specification.
- Initial Worst Case S21 Figures From Dawson Received. Transfer
Function Being Transfered Into Matlab Model For Generation Of Data
Eye For Evaluation Of Dj. (Anthony)
La (Jan) Simulations From Mysticom And Ifx Show That The Wc
Compliance Channel As Supplied By Dawson Is Giving Too Much
Amplitude Attenuation, Given A Value Transmit Eye.
Xaui Group Has Decided To Currently Accept A Average Channel From
The Measurement Data, Although Concerns Still Exist That The Current
Data May Still Be Best Case When One Starts Looking Toward Thicker
Backplanes. (The Method Of Layer Connection And Via Stacking Being
One Of The Most Critical Parameters). In Addition A Maximum Group
Delay Of 80ps Was Defined.
- Dawson Supplied Polynomial For The Transfer Function.
A- Jitter Group Must Decide Whether To Accept Min/Max Channel
Compliance, And New Jitter Numbers. (See Complete Model)
- From Initial Simulation (Ifx) An Upper Frequency Of 3.125ghz For
The S21 Information Would Seem To Be Sufficient. Question Exist
Concerning The Phase Response For Upper Frequencies. Also, It Is
Important That The Attenuation Has Then An Upper Limit Defined
>3.125ghz.
- The Losses In The Interface Shall Be Defined For The Channel And
For Other Losses (E.G Crosstalk). The Other Losses Shall Be 2,5db
Flat Across The Entire Bandwidth. Channel Loss Being Approx 7,5db
For 2.5ghz.
After Verification Of The Ifx Simulation Results By One Of The Other
Groups, A Final Decision Shall Be Made To Accept The Proposed
Compliance Channel.
4.4 Fext/Next (Cross Talk)
Crosstalking Effects Consists Of The Following Phenomina
- Amplitude To Phase Noise
- Direct Dj
- Supply Crosstalk
- Other Chip Crosstalk
Currently Defined As 0.4% Of 800mv, Or 0.07 Tj, And X.Xx Dj.
Crosstalk Could Be A Big Issue As Loosely Coupled Differential Strip
Lines Are Currently Seen As The Preferred Solution For The Xaui
Channel. This Leading To Increased Differential Noise Issues. Also
It Is A Concern That Crosstalk At Connectors Could Be High.
Common Mode Noise Could Be Also Be Converted To Dj At The Reciever.
Comment From Ali, That Connector Shall Be The Biggest Form Of
Crosstalk.
- Crosstalking Specifications From Typical Connectors To Be
Collected From Connector Manufacturers By Ali.
Closed.
- Theoritical Simulation Of Expected Differential Crosstalk To Be Done (Anthony)
Basically have seen that crosstalk on PCB and package is nothing.... <-60dB.
- Shelto provided Datasheets For Typical Connectors To Dawson,
Who Will Draw Some Conclusions.
- Dawson has sent out email concerning conclusion to information
provided by Shelto. Some questions exist with reference to signal
detect point raised by Joel, and also feedback from connector
distributors.
4.5 Connectors & Vias (Current Budget Probably Not Enough)
Currently It Would Seem That Current Assumption Concerning Channel
May Be Too Optimistic. (Pcb Loss With Connectors Looks More Like
-15db Stat. -10db.)
Initial Work From Aglient Work Did Not Include Connectors
- Comment From Ali Is That Xaui Goal Was 16". (Confirm).
- Confirmed Is That Xaui Goal Is 20" (Ali, Rich)
- Pcb With Connectors Are Being Assessed By Compliance Group, And
Will Be Covered In Some Form (See Current Worst Case Channel
Compliance S21 Figures).
- Connector Tolerances
4.6 Return Loss
Concerns Exists Concerning Current Rl Specification.
- Verification Of Max/Min Capability Of Rl Required. Distance Of
The First Connectors From The Driver Should Be Verified For Wc.
- Proposal First Raised By Jeff Cain And Tom Grey
The Initial Simulation Results Of Ifx Using The Compliance Channel
And Estimation For 1/4lambda Connectors Would Show An Acceptable
Data Eye Given A Return Loss Of -8db. This Results Should Again Be
Verified By One Of The Other Simulations Current Being Run By Jeff,
Or Tom.
A- ("Ishwar Hosagrahar" <Ishwarh@xxxxxx>) To Take Over Action Of
Providing Nformation Concerning This Requirement.
- Perhaps Rl For Receiver Should Be Left At 10db.
- Comment From Ron Miller. (See Below)
************************************************************
Hi Anthony
I Just Got Back From Boston So Could Not Join Your Concall.
However, When I Read Your Agenda My Hair Stood On End. 8 Db
Should
Not Be A Consideratiopn For Return Loss.
If It Should Be Changed It Should Be Tightened Up To 18 Db And
Should Cover The Frequency Band From 200 Mhz To 10 Ghz. If
Anyone Makes Equipment That Poor(8db) I Can Assure You That All
The Other System Specs Will Be Violated With 10e-12 Ber
Available Only For Inch Length Traces. There Are Some Real Bad
Trade-Offs Here.
Please Post This For Comments.
Ron Miller
************************************************************
A- Proposal To Be Entered For Transmit And For Receiver
- 10db <= Baud/2, 8db > Baud/2
- Return loss originally was intended only for receiver (10 dB
diff, and 5 dB common mode). It would very difficult to meet to
meet transmit return loss. In the IB we added Zdiff, ZSingle_Ended,
10% matching, but not the return loss (Ali comment)
4.7 Group Delay Of Channel
A- Comment To Be Entered That Group Delay Definition To Be Removed
And A Minimum Dj Should Be Defined That Must Be Induced By The
Channel, For A Given Pattern, And Transmit Waveform.
Based on the current email traffic there still seems to be the
opinion that it is not possible to pin down the group delay of a
compliance channel
(D) The compliance channel group delay spec appears "broken".
A- There is some work in progress toward a solution. (Note 1)
4.8 S11 For Channel Definition
Although It May Seem To Make No Sense In Defining Rl, As For Channel
Compliance A Worst Case Rl Is Required, For A System Designing
Wishing To Design A Pcb That Should Work With Two Already Available
Chips; The Designer Must Know How Good The Performance Of The
Channel Must Be. To This End The S11 Must Be Defined.
A- Comment Should Be Entered, Exact Numbers To Be Set In Next Telco.
4.9 AC Coupling (Email from Mike Jenkins)
>From the teleconference this morning, I owed a response on the
issue of AC coupling in the standard 100 ohm load, in particular,
the pole frequency of the AC coupling. For passing 8B/10B coded
data, table B.1, "Fibre Channel - Methodologies for Jitter
Specification" a ratio of pole frequency to bit rate less than about
0.0002 produces insignificant jitter (due to the capacitor's
non-zero impedance). Hence, pole frequency < 0.0002*3125 MHz =
0.625 MHz. For my money, 1 MHz is close enough. The smallest value
blocking capacitors I've seen in applications is 2400 pF, which, on
a 50 ohm line, yield a 1.326 MHz pole. Likewise, 0.01 uF yields
0.318 MHz.
One other effect to consider is that (assuming the measurement is
taken after the blocking capacitor), while the capacitor's non-zero
impedance introduces jitter, it acts as a high-pass filter.
Therefore it actually REDUCES the jitter created by the channel.
Hence, the pole frequency should be restricted from being too high
to preclude accidentally or intentionally optimistic measurements.
In summary, I think 1 MHz is a good value, permitting use of
reasonably valued capacitors and minimizing jitter induced by the
coupling capacitor itself.
------------------------------------------------------------
5. Equalised Compliance Testing
The Use Of The Compliance Channel (Including Random Noise) And
Receive Jitter Budget For The Compliance Testing Of An Equalised
Transmitter Was Agreed Upon And Fixed.
------------------------------------------------------------
6. Compliance Patterns
6.1 Jitter Strategy
6.1.1 Purpose Of Jitter Test Patterns:
To Be Used For Verifying Compliance To Clause 47 Jitter
Specifications For Xaui Transmitters And Receivers.
Patterns For Other Jitter-Related Purposes Are Not Subject
To Standardization.
Requirements And Desirable Properties:
- Expose All Reasonably Significant Weaknesses That Could
Cause Interoperability Problems Due To Jitter Effects.
- Stimulate All Four Lanes
- Simple To Generate From Test Equipment And Xaui Circuits
- Simple To Analyze In Test Equipment And Xaui Circuits
6.1.2 Test Equipment Limitations
6.1.2.1 Pattern Generation For Receiver Test:
A Differential Four-Channel Pattern Generator With Individual
Control Of Pattern, Amplitude And Timing On Each 3.125gbit/S
Channel Would Be The Ultimate Instrument For Testing Xaui
Receivers. In Lack Of One, Other Options Must Be Investigated.
I Have Found Single-Channel Complementary And Two And Four-Channel
Single-Ended Generators. Since They Have Ample Amplitude Ranges
Power Splitters Can Be Used To Create Four Differential Lanes.
The Output Signals From The Splitters Can Be De-Skewed And Filtered
By Twisted Pair Cables To Introduce Isi Jitter For Eye Degradation.
With The Two-Channel Generators, Patterns Are Limited To Columns
Of Identical Or Inverted (Crossed) Bit-Patterns. A Fair Amount Of
Testing Can Be Done That Way. A Four-Channel Generator Offers More
Options. Two Of The Channels Can Be Operated Complementary And
Split 1:3 To Be Used As Aggressor Channels With Identical Data,
While The Remaining Two Channels Are Used For The Victim Channel.
Conclusion: There Should At Least Be A Set Of Patterns Specified
Which Are Limited To Equal Or Inverted Data Columns Across The
Xaui Lanes.
6.1.2.2 Xaui Transmitter Jitter Measurement:
The Tails Of The Edge Timing Distributions Can Be Extrapolated
Down To 10e-12 With A Tia Or Bert Scan. Measured On One Channel
At A Time, At Transmitter Output Or End Of Reference Channel.
Full 3.125gbit/S Rate Must Be Supported For Full Exposure Of
Transmitter Isi.
Conclusion: The Transmitter Must Generate A Pattern With A Fair
Amount Of Isi-Exposing K28.5 Or Equivalent.
6.1.3 Pattern Types
Xaui Protocol Compliant Patterns Offer The Advantage Of Some
Freedom In Choice Of Locations For Pattern Generation And
Analysis. I Don't See A Need For Specifying Non-Compliant
Patterns, Neither For Coverage Reasons Or Because Of Measurement
Methods Or Equipment Limitations.
Both Wide Spectrum (Random)-Type Patterns And Cdr Test Patterns
Of Cjtpat Type Can Be Fit In Compliant Frames.
The Xaui Idle Pattern Generator Has A Fairly Well Spread Spectrum.
By Detailed Standardization Of The Algorithm, It Can Be Used In
A Random Pattern Test. It Is Compliant And Can Go On Forever
Without The Limitations Of Packet Residing Patterns. It's Short
Enough To Allow The Receiver To Hunt For Synchronization Without
A Marker. It Comes For Free On The Transmitter Side.
The Cjtpat Assumes That Clock Recovery Plls Will Have Phase Lock
Equilibria At Different Extremes For A 1010101... Pattern Vs.
A 111110000011111... Pattern. Repeating Them Long Enough For The
Phase Locked Loop To Stabilize At The Extreme Will Then Constitute
The Largest Systematic Risk For A Bit Error When Moving From One
To Another. In Some Cases Patterns Of The K28.5 Type Will Probably
Be Worse As Successors To Long Periods Of Any Of The First Two
Patterns. With Some Care In Putting Together A Cjtpat Type Pattern
That Case Can Easily Be Taken Care Of.
6.1.4 Summary:
Patterns With Crpat And Cjtpat Properties Can Be Made Compliant
In Four-Lane Versions For Xaui.
Test Equipment Limitations Can Restrict The Possibilities For
Generating Patterns Exposing Many Kinds Of Cross Talk.
Test Of Lane De-Skewing Capabilities Delay Adjustment Capabilities
Beyond The Readily Available. Yet, Such A Test Would Probably Be
The Most Demanding For A Receiver Cdr.
6.2 Basis Of Fc Jitter Pattern (Contribution From Tom Lindsay)
6.2.1 Purpose/Background
Low Frequency (Within The Passband Of The Cdr Pll) Variations In
Transition Density May Be Combined With Isi Jitter Or Mechanisms
Internal To The Cdr, Such As Phase Detector Offset. The Cdr May Track
These Variations, And Low Frequency Jitter Can Occur Within The
Cdr. Cjtpat Was Developed To Test For Such Situations. After Each
Tracking Due To A Run Of Low Or High Transition Density, The Cdr Is
Hit With Bit Sequences Associated With The Opposing Jitter. Because Of
The Tracking, The Peak Jumps In Jitter Are More Severe Than If The
Tracking Had Not Occured. This In Turn May Lead To Higher Bit Error
Rate.
6.2.2 Pattern Content
Cjtpat Includes:
6x Fc Idles (24 Characters)
Sofn3- (4 Characters)
Payload (228 Characters, Including Header)
Crc (4 Characters)
Eof (4 Characters)
For Ethernet, Obviously The 6x Idles, Sof, And Eof Will Have To
Change. The Payload Is Really What We're After.
The Payload Consists Primarily Of 7e's And B5's. However, Transition
Characters Also Exist. These Transition Characters Are Very Important
To The Pattern.
167 7e's (30% Transition Density, Minimum Sustainable In 8b10b)
1 74
1 7e
1 Ab
51 B5's (100% Transition Density, Maximum Sustainable In 8b10b)
1 5e
1 4a
4 7e's
1 Fe
Total = 228 Characters (57 Fc Words)
Looking At The Attachment, There Are Particular Bit Sequences That
Occur. These Are Highlighted In Red.
The First Is In The Transition Between The 167 7e's And The 51 B5's:
In The 74, A Single 1 Occurs After A String Of 4 0's;
Then A Few More Wide-Spaced Sequences Occur;
In The Ab, A Single 0 Occurs After A String Of 4 1's.
The Second Transition Sequence Is After The 51 B5's:
In The 5e, 4 Contiguous 0's Occur After ...0101;
Then A Few More 1010... Sequences Occur;
In The 1st Of The 4 7e's, 4 Contiguous 1's Occur After ...1010.
These Transitions Are What Make Cjtpat Interesting. The Long Repeating
Runs (167 7e's And 51 B5's) Are Used To Move The Cdr Alignment Over,
But Then These Particular Bit Sequences Maximize The Phase Jumps That
Give The Sample And Hold Circuits Their Challenges. So, Don't Attempt
To Build The Pattern Without These Transitions.
6.2.3 Pattern Lengths
I Assumed That One Might Design Their Cdr Corner Frequency To Be As
Low As Dr/1667. If We Convert That Corner Frequency Into A Time
Constant (Assuming A Single Pole Model), The Time Constant Is Approx
267 Bits Or 26.7 Characters. The Average Transition Density For 8b10b
Code Is Approx 60%, So The Time Constant Can Be Converted To Approx
160 Data Transitions.
For Cdr Shifting To Be Complete (~95%), At Least 3 Time Constants Are
Required For Settling.
(The Next Part May Be Controversial). Most Cdrs Show A Straight
Dependence Between Bandwidth And Transition Density - That Is, Time
Constant Is Inversely Proportional To Transition Density, Or Settling
Is Directly Proportional To The Number Of Data Transitions. If The Cdr
Exhibits A "Corner Frequency" Of Dr/1667 At 160 Transitions, Then
3 Time Constants At 100% Transition Density (The B5's) Results In 3
X 1bit/Transition X 160 Transitions = 480 Bits = 48 Characters.
3 Time Constants At 30% Transition Density (The 7e's) Results In 3 X
3.3bits/Transition X 160 Transitions = 1600 Bits = 160 Characters.
After Building Up The Pattern, I Used A Few More Of Each, Mostly
Because Of Additional Constraints Of Least Common Multiples With Fc
Words And Bytes For Ber Testers.
If Folks Feel This Relationship With Cdr Bandwidth And Transition
Density Is Not Valid, Then Pattern Lengths Can Be Adjusted.
6.2.4 Other Notes
1. Starting Running Disparity Is Important. The First 7e In The Long
Run Must Start With Positive Running Disparity So The Correct
Character (1000011100) Is Taken From The Table. Otherwise, The
Transition Sequences Do Not Work.
2. The Last Character Is Fe. This Was Chosen To Determine A Crc That
Ended In Positive Running Disparity, So That The Fc Eof Used The
Alternate Disparity (1100000101) Of The K28.5 (Fc Idles And Sof All
Use 0011111010). This Is Probably Not Critical (See Below), But
Provides Both Polarities Of The Comma.
3. Worse Case Bit Patterns Are Possible If K Characters Are Allowed,
But Cjtpat Was Constrained To Be A Valid Fc Frame. K Characters Were
Not Allowed In The Middle Of The Frame. For Example, The 4 0's
Followed By A Single 1 Is The Worst Case Situation Of This Type
Allowed With D Characters. The 5 0's Followed By Single 1are Provided
In The Pattern At Its Ends, But These Are Less Interesting Because The
Cdr's Will Be Somewhat Re-Centered When They Occur.
6.3 Random Jitter Measurement Of K28.7
An Open Question Concerning The Ability To Measure Random Jitter
Using The K28.7 Code Was Clarified. The K28.7 Code In Combination
With Normal Data Eye Methods Is Prone To Picking Up Bounded
Uncorreleted Code. Use Of Bert Methods Are Therefore Recommended For
Rj Measurements.
6.4 Defined Patterns
- The Current Annex 48b Proposal Contains The Following Patterns.
- High Frequency (Short) : Rj
- Low Frequency (Short) : Rj + Pll Tracking
- Mixed Frequency (Short) : Rj + Dj
- Crtpat (Long) : Overall Jitter In System
- Cjtpat (Long) : Jitter Tolerance
- Patterns Based On Fc And Gigaethernet
- Patterns Are 8b10b Specific, And Do Not Cover Scrambled, Or 64b66b
Based Data
- Proposal Covers Problems Of Independant Lanes
- High, Low And Mixed Frequency Patterns Same As Fc
- Needs A Little Work On Pattern Run Length
- Patterns Transmitted On Each Channel Should Be Same And
Sychronised For Each Channel.
- Long Patterns Should Be Generated At Mac Level. Using Methods For
Generation Of Patterns In Recieve Direction Similiar To Fc.
- Short Patterns Are Generated With Register Enabling. Please Note
These Patterns Must Be Manditoryly Generated.
- Disparity On Each Four Lanes Could Be Different
- Opinion Is That This Does Not Need To Be Controlled
- Half Pattern Runs With +Ve Parity And Half With -Ve
- Non 8b10b Patterns Shall Be Left Out Of Specification.
- Additional Spat And Cspat Should Not Be Needed
a- Final Acceptance Of Proposed Pattern.
Tom.L Has Sent Via The Reflector A Proposal For The Cjtpat, Based
On The Inputs From Mysticom, Conforming To The Required Packet
Length. The Pattern Is Generally Accepted For Compliance Testing Of
The Xaui Interface, However, Up Until The Next Plenary Comments
Should Be Sent To The Reflector
- The current defined patterns are finally fully accepted as being part of the v3.0 specification.
A- It Was Requested That Rich Could Possibly Explain How The
Compliance Pattern Can Be Generated From Mac.
6.4.1 Compliance Definition
The Following Points Are Currently Agreed.
- Only A Single Pattern Should Be Defined For Compliance.
- The Majority Of Manufacturers Shall Implement The Ability To
Transmit Simple 8b10b Code Words I.E High/Mixed/Low Frequency
Patterns.
The Following Points Must Still Be Discussed In Some More Detail, On
The Reflector.
- Cjtpat For Transmitter Dj And Rj Compliance.
- Cjtpat Will Give Different Numbers In Comparison To Short
Patterns. This Means That The Currently Defined Jitter Numbers
May Have To Be Adjusted.
- Transmitter Must Be Capable Of Generating The Cjtpat. This
Could Be Accomplished Through Bert Scan, Or Mac.
- Consistency In Results Of Dj And Rj Using Such Long Patterns.
- Complexity Of Such Transmit Patterns.
- Using Same Pattern For Transmit And Receive Compliance Should
Guarentee Better Compliance Between Devices.
- Use Of Cjtpat As A Receive Tolerance Pattern Causing A Worse
Case Jump In The Cdr, In Comparison To Other Simple
Patterns. (Minor Point As It Would Seem Clear That This Is The
Case.)
- A Note Of Caution From Ali
- Pattern Should Not Be Too Complicated And Long As This Can
Lead To Complication With Measurement Equipment.
- Pattern Should Be Such That Implementors Can Use This
- Mixed Frequency Or K28.5 Could Be Sufficient
- Serial Pmd, Current Using Simple Scrambler Pattern With
Additional Influence From A0/A1 Bytes For (Wan Phy)
- Does Cjpat Require Other Jitter Budgets.
- Adhoc To Remain With Use Of Cjpat And Hpf For Compliance Testing.
- Refer To Emails From Tom.L To Be Included In Jitter Issue List.
- Matlab Phase Model To Verify Use Of Hpf And Cjpat (Ifx)
- Results of Matlab model can be referenced from reflector
presentations from Infineon. These simulations currently show that
the effect of HPF and CJPAT leads to an increase of the DJ from
the current simulations by 65%.
Current channel simulation are showing about 0.123UI, therefore
with additional 1.65 from HFP effect we have 0.2UI, which agrees
approximately with current specification.
a- Additional 0.05UI of jitter must be found from somewhere. This
is to be discussed in following telco. Solved see below.
- There is voiced concern from Piers concerning the use of CJPAT as a
compliance pattern.
A- Must we add the DJ really together...??? We must somehow decide whether all this jitter is data dependant and correlated or not. This would allow us to use convolution, which may give as a few mUI here and there.
A- Tom to repost information concerning effect of random jitter on effective DJ.
A- Proposal to solve the current jitter specification.
- Increase channel jitter to 0.2UI
- "Other" should be treated as SJ depending upon whether we are talking about compliance testing or system budget.
- Make "Other" 0.1UI for system budget to avoid confusion.
6.4.1.1 Background For Cjpat And Hpf For Compliance (Tom Lindsay)
Fibre Channel (Fc) Understood That Cdrs Track Low Frequency Jitter,
And That Including This Effect In The Specifications Could Ease
Requirements On Clock Oscillators (Lower Cost Designs Tend To
Exhibit Low Frequency Random Jitter), Serializer (Serdes, Same
Advantage) Designs, And Switching Power Supplies, Layouts,
Bypassing, Etc. With All This In Mind, All Fc Jitter Output
Specifications Include The Effects Of A High-Pass Filter (To
Suppress The Significance Of Low Frequency Jitter) To Emulate Cdr
Tracking.
Fc Also Realized That, Due To Frequency Content, Long Complex
Patterns Cause Phenomena That Are Not Observed With Short Patterns -
Data Dependent Jitter (Ddj, A Form Of Deterministic Jitter) Can Have
Extreme Ranges Of Frequency Content From Well Below To Well Above
The Cdr Corner Frequency. Effects Are Usually Seen In Both
Transmitters And Receivers. Since Such Long Complex Patterns (Such
As Cjpat) Can Exist In Real Systems, They Must Be Included Somewhere
In A Set Of Specifications For A Standard.
Some Observations:
- High Pass Filtering (Hpf) Is Appropriate For The Reasons Given
Above. If Hpf Is Used, Then (At Least In Some Test Methods), Hpf
Will Naturally Also Be Applied To Ddj.
- Without Hpf, Due To Transmitter Interactions, Long Complex
Patterns Usually Result In Worse Pk-Pk Ddj Output Than
+/-K28.5s, Although Differences Are Typically <10%.
- With Hpf, I Have Observed That Cjpat-Type Patterns Can
Increase Pk-Pk Ddj By More Than 50%. However, When Considering
Equivalent (Bathtub Curve-Fitted) Deterministic Jitter, This
Increase Will Be Somewhat Reduced In Relation To The Amount Of
Random Jitter Present.
- In Any Case, Hpf Emulation Implies That Cdrs Will Have More
Trouble With Cjpat Than +/-K28.5s, And I Have Observed This In
The Lab With Cjtpat.
- Jitter Budgeting Must Be Based On Long Patterns, Since They
Are More Challenging And Represent Likely Scenarios In Real
Systems. However, This Still Leaves Open The Debate On Test
Methods, Data Patterns, And Jitter Test Limits. That Is, It May
Be Possible To Have Jitter Test Limits That Are Different Than
The Jitter Budget.
Now, For The Debate - Assuming That Hpf Is Used (Do We Want To
Debate This One?), Data Pattern Options Are:
Jitter Output :
Short Pattern :
- Set Tighter Test Limits To Anticipate Greater
Jitter Output So That Long Patterns Still Stay
Within The Budget.
- The Amount Of Tightening Will Take Some Thought,
And Will Be A Function Of Random Jitter, Etc.
Long Pattern (Cjpat) :
Set Test Limits Based Directly On The Budget.
Jitter/Signal Tolerance :
Short Pattern :
- Set Test Conditions Worse Than The Output Jitter
Budget To Anticipate The Receiver's Response To Long
Patterns.
- The Amount Of Increase Will Take Some Thought And
Will Be A Function Of Random Jitter, Rx Bandwidth,
Etc.
Long Pattern (Cjpat)
- Set Conditions Equal To Output Specs, Which In
Turn Are Based Directly On The Jitter Budget.
4 Combinations Exist From Above. My Opinion Is Probably Obvious: Use
Long Patterns For All Jitter Budgeting And Specifications In The
Standards.
- Using The Same Pattern For Everything Provides A
Self-Consistent Set Of Specifications, And Making It A Long
Pattern Helps Ensure That Real Mechanisms In Real Systems Are
Flushed Out.
- The First Role Of The Standard Should Be Technical Rigor -
Ahead Of Simplicity.
- Let Test Simplification Be An Option To Those Implementing The
Standard At Their Own Risk And Benefit. Specifically, Leave
The Interpolation/Extrapolation Required With Short Patterns To
Those Who Truly Understand Their Own Products And Are Interested
In Simplifying Their Test Environments. They Are Free To Do So.
- The Standard Does Not Have To Deal With The Non-Trivial Task
Of Determining Relationships Between A Jitter Bugdet And Test
Limits Across A Range Of Technologies And Products Yet To Be
Developed.
6.5 Test Equipment For Pattern Compliance Testing
- Additional Points To Proposal
- Independant Timing Skew For Each Of The Four Channels Is Really
Needed.
- Testing One Channel Independantly To The Other Channels Could Be
Too Worst Case!!! As This Would Lead To A Possible High Low
Frequency Jitter Between Channels.
- Compliance Test Should Try Cover All The Possible Phenomina In
One Test, As Opposed To Trying To Seperate Out Phenomina. (This
Can Be Done For Diagnostics).
- Can Standard Idle Pattern Generator Could Be Used As Random
Pattern Generator.
------------------------------------------------------------
7. Ber Definition
Currently The Xaui Interface Is Defined As Having A Quality Of
10e-12, This Gives An Equivalent Of 14xrms For Peak-Peak Jitter To
Give 10e-12 On Single Channel Basis, But What Is Required For 10e-12
Over All Four Uncorrelated Channels. This Point Must Be Clarified.
In Various Meeting We Have Discussed Ber Of A Lane Vs The Channel.
The Basic Assumption Here Is You Are Sending 4 Times The Amount Of
Data And 4 Time The Error Rate, The Resulting Error Rate Still
Remains 1e-12. Even If You Look From The Point Of A Packet Getting
Zapped The Probability Remain The Same 1e-12 As A Packet Takes 1/4
Of Time To Cross A Xaui Channel.
Extention Of Discussion To Complete Ber Expected From Concatenated
Xaui-Optical-Xaui Links, Each Defined As Having A Ber Of 1e-12 Is
Not Practically Interesting.
- Quantify Better Rich´S Concerns Concerning The Ber Of The Xaui
Link Wrt Pmd Link. (Next Telephone Conference). The Question Of
Overall Ber For The 10gbe Link Was Discussed Again In La, And The
Issue Of Total Overall Ber Was Consider Outside The Bounds Of
Measurement.
------------------------------------------------------------
8. Instantaneous Bit Shift
A Serious Concern Raised Is Associated With Possibility Of 0.65 Ui
Of Instantaneous Jitter Causing Bit Shift. In The Original Hari
Proposal Due To This Concern The Maximum Dj Was Limited To 0.41 At
The Receiver And 0.17 Ui At The Transmitter. (Comment From Ali)
This Issue Was Discussed In The Hari Group And The Total Dj Was
Limited To 0.41 Ui Because Of Instantaneous Jitter. Even 0.41 Ui Is
Already Challenging For Many Serdes Designs. (Comment From Ali)
------------------------------------------------------------
9. Sonet Sj
In The Traditional Sonet The Only Required Specification On The
Receiver Is For Tracking Low Frequency. In Addition It Was
Requested The Random Component Of Xaui Link Be Specified So It Will
Not Be Concentrated At One Frequency Specially Near The Bit
Rate. (Comment From Ali)
Sonet Link Only Specify Sj For Jitter Tolerance, Which Is Easier To
Meet Than Full Dj+Rj With Fc Scaled Sj. Sonet Specifies 0.15 Ui Of
Sj At After The Right Most Break And Fc Specifies 0.1 Ui, But With
Fc You Have The Additional Dj+Rj. Sonet Link Primary Concern Is
Jitter Generation And Transfer. In The Case Of Copper Link You Will
Have High Amount Of High Frequency Isi, Therefore We Need To Limit
The Instantaneous High Frequency.
Trying To Specify The Random Jitter Such That It Will Not Be
Concentrated At One Frequency Will Be Difficult To Verify And Test.
You Would Need To Use Phase Noise Measurement With Multiple Filter.
If We Want To Add An Specification Here It Should Only Be Based On
Viewing The Relative Noise Spectrum, Not Trying To Measure Rj As
Function Of Frequency. Even This Will Be Challenging As The
Oscillator Phase Noise Will Broaden Each Of Data Peaks.
------------------------------------------------------------
10. Overall Verification Of Jitter Budget
- Polynomial Available From Compliance Group.
a- Ongoing Simulations For Verification Of Newly Proposed Jitter
Numbers And Patterns Are Ongoing By
- Jeff Cain
- Tom Gray
- Ifx
- See Below
- Mysticom
- See Below
- Dawson
Use Of High Pass Filtering When Assessing The Transmit Eye Should Be
Used When Assessing Long Patterns To Account For Tracking
Behavior. See 6.4.1.
Methods For Inclusion Of Maximum Group Delay In Simulations Should
Be Assessed Carefully.
Additional Amplitude Noise Should Not Be Forgotten About When
Assessing The Simulation Results For Receive Eye.
Simulation Results From Ifx :
Showed Various Setups Using The Compliance Channel, Reduced Return
Loss And Additional Connectors At 1/4 Lambda Distances From
Transmitter And Receiver.
The Following Comments Were Made
- The Data Eye Should Be Regenerated, With A Single Eye To Give
A Complete Data Eye
- The Method For The Positioning Of The Data Eye Should Be
Explained.
- If Possible Confirmation Of Cjtpat With A Hpf
- The Model Is "Really" Worst Case
A- The Source Of The X2 For The Receive Data Mask Should Be
Explained In The Coming Weeks.
- It Is Vital That Confirmation Of These Simulation Results From
The Other Participants Be Made Available As Soon As Possible.
The Following Conclusion Can Be Current Drawn
- The Proposed Channel Can Be Accepted
- The Proposed Group Delay Deviation Can Be Increased To 200ps
- The Return Loss Can Be Relaxed To -8db
- The Proposed Sj Of 0.1ui Is Acceptable
- There Would Appear To Enough Margin For Additional Amplitude
Noise
Simulations Results From Mysticom :
- Results From Simulation From Mysticom (Available From Ieee
Internet Page).
- Results Look Positive For Current Specified Channel, However,
Simulation Is Not For Cjpat And Does Not Include Pll Tracking
Phenomina.
Status From Dawson :
- Simulations Just Started. Matlab Generated Trap. Waveform, With
Gaussian Rj And Lp Eye To Give Dj. Ideal Driver With Termination
Resistor And Capacitance, And Lumped Ladder Model For Channel,
With Lumped Connectors. Alterating K28.5 Pattern Used.
- Compliance Channel Eye Is Looking Open, Figures To Be Released
Soon.
Measurement Results from Giga
Some investigations from Giga (distributed on the reflector, show
limitations of currently available DEMUXs. These results would
initial show that the current jitter budget for the XAUI interface
is too aggressive for the receive side. This results are based on
SONET tolerance testing, and it is currently the opinion of IFX
that the peak to peak sinusoidal 1dB penality, cannot be directly
used to show the performance of the receiver, but must be first
converted to a offset specification.
A- Convertion of the SJ jitter from Giga into absolute time offset
must be done (Ant)
Ongoing,... have models runnning at the moment, and hope to have results in the coming week.
The actions concerning results for the channel simulation can be now closed.
11. XAUI signal detect
- See email from Joel Dedrick <Joel_Dedrick@xxxxxxxxxxxxxx>
- It is currently considered that signal detect mecanisms are
possible. (reference to Infiniband)
(D) The XAUI signal detect issue was unanimously resolved: There is no additional signal_detect pin or mandatory loss-of-signal detection on the XAUI. This was the only change to clause 47 in going from D2.2 to D2.3. (The D2.3 draft now available to task force members on the web site.)
12. Frequency Tolerance Measurement Methodology
- Tom has put email out on reflector, comments moving. Issue is more
definitional as opposed to critical
13. Electrical Specification
13.1 Amplitudes
- In Tampa meeting we agreed the RX amplitude will be fixed to
1600 mV and TX need to be determined. Here you need some margin and
as allowing some reflection. Probably maximum TX need to be
lowered. (comment from Ali)
- Fig 47-4 assuming measured with an ideal load does not include 4%
cross talk which equates to 63 mV under worst case scenario of 1600
mV and 200 mV. Loss allocation in the table 47-6 specifies 4.5 dB
for others but according to eye diagram Fig 47-4 some one may
introduce more loss. The 4% crosstalk results in 31% additional eye
closure with an actual XAUI receiver. Return loss penalty
associated with a XAUI receiver gets absorbed in to the SerDes
effective sensitivity, but the crosstalk may not. As the biggest
source of the crosstalk is the connector. (additional comment from
Ali)
A- Thought about above comments welcome
13.2 Differential Skew
- Differential Skew can't be measured separately from DJ even if you
are sending 1010, you still may have DCD. The total DJ already
include the Diff_Skew so I would propose removing it since it can't
be measured. (comment from Ali)
- Similar comments made by Tord. Conclusion is to remove this from
the specification.
A- Comment to be entered and accepted.
13.3 Definition of ISI loss vs Other Losses
- It seems to me the connector loss is lumped as part of
interconnect loss resulting in 7.5 dB of loss. Under some cases
where the 7.5 dB is just ISI some implementation may not work. We
should try to separate ISI loss from connector+misc+croasstalk
loss. (comment from Ali)
A- Thought about above comment welcome
14. Receive Equalisation
It should be noted again that the IEEE specificies compliance for
transmitters with and without equalisation, but does not restrict an
chip developer from implementing receive equalisation. However, it
is clear depending upon the implementation the defined transmit
jitter specification could be violated.
------------------------------------------------------------
Section 47 Attachment
------------------------------------------------------------
47.4.1 Jitter test requirements
Terms and definitions for effective jitter and random error processes
as used by this specification are defined in Annex.48B.1 and should be
studied carefully before compliance testing is started.
47.4.1.x Transmit Output Jitter
47.4.1.x.x Transmitter With No Implemented Equalization.
The output of the driver when terminated as defined in section
47.3.3 and measured using one of the reference methods as defined in
Annex.48B.3 shall conform to
a) the specified transmitter deterministic and random jitter as
defined in table 47-2, and
b) the data eye as defined in figure 47.7 and table 47.4.
under the conditions that
a) the transmission pattern is CJPAT, as defined in Annex.48A,
------------------------------------------------------------
b) the extracted clock used for measurement is High Pass Filtered
with a corner frequency of 3.125GHz / 1667 and 20dB rolloff, based
on the theory presented in of Annex 48B.1.5, and
------------------------------------------------------------
c) all other channels in the transmit and receive direction are
active.
47.4.1.x.x Transmitter With Implemented Equalisation
Using one of the reference methods as defined in Annex.48B.3 both
a) the output of the driver when terminated as defined in section
47.3.3 and
b) the output of the filtered driver where the filter has a worst
reponse than defined for the compliance channel, section
47.3.3.5. and is terminated, as defined in section 47.3.3
shall conform to
a) the specified receiver deterministic and random
jitter as defined in table 47.5, and
b) the data eye as defined in figure 47.4 and table 47.3 (without
sinusoidal jitter)
under the conditions that
a) the transmission pattern is CJPAT
------------------------------------------------------------
b) the extracted clock used for measurement is High Pass Filtered
with a corner frequency of 3.125GHz / 1667 and 20dB rolloff, based
on the theory presented in of Annex 48B.1.5, and
------------------------------------------------------------
c) all other channels in the transmit and receive direction are
active and terminated with valid data. (Clocks are not synchronised.)
47.4.1.x Receiver Tolerance Testing
Using one the reference methods defined in Annex.48B.2 the receiver
shall tolerate the specified deterministic and random jitter as
defined in table 47.5 given the additionally applied sinusoidal
jitter mask, section 47.3.4.4., for all frequencies, under the
conditions that
------------------------------------------------------------
a) a stressed signal with data eye opening amplitude equal to
receiver sensitivity, defined in 47-4, but conforming to the data
eye defined in 47.4, generated given the reference method defined in
Annex 48.B.4. is used
------------------------------------------------------------
b) all other channels in the transmit and receive direction are
active. Include clock offset
c) the received pattern is CJPAT
------------------------------------------------------------