XAUI Jitter Adhoc Protocol 24th January 2001
Gentlemen,
please find included the protocol for the XAUI Jitter Adhoc Protocol
24th January 2001, plus updated "XAUI Jitter Issues List".
Best regards,
Anthony Sanders
Principal Engineer
Infineon Technologies
Munich, Germany
XAUI Jitter Protocol
24th January 2001
Chair:
Anthony.sanders@xxxxxxxxxxxx <anthony.sanders@xxxxxxxxxxxx>,
Attendants:
Ali Ghiasi <aghiasi@xxxxxxxxxxxxx>,
Kesling Dawson W <dawson.w.kesling@xxxxxxxxx>,
Tom Lindsay <Tom.Lindsay@xxxxxxxxx>,
Jeff Porter <j.porter@xxxxxxxxxxxx>,
Mike Jenkins <jenkins@xxxxxxxx>,
Rich Taborek Sr. <rtaborek@xxxxxxxxxxx>,
Tord Haulin <tord.haulin@xxxxxxxxxxxxx>,
Tom Gray <tgray@xxxxxxxxxx>
Jason Chen <jchen@xxxxxxxxxxxxxxx>,
Protocol: (Sections numbers are based on XAUI Jitter Issue List)
2.5 IEEE Sections, Annex´s and References
- 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 this document 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
- Technical Inputs : Ali, Tom.L, Mike.J, Anthony.S
- Rich.T shall prepare initial draft for next week´s editors
meeting
- Entire team shall meet at "Fiber channel meeting" in 2 weeks to
finalise contents of Annex.
- 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).
A- Section for Clause 47 to be written (Anthony, end week).
- This section should include the statement.
"During compliance testing of a XAUI channel using the
patterns described in Annex 48A, all channels in co-direction
should be active with the same pattern, the system providing a
natural skew of these channels, and all channels in the
contra-direction should be asynchronously active with valid
XAUI data."
- This section shall reference Annex 48A and the additional
methodology annex´s to be written, adding statement specific for
electrical testing of the XAUI interface.
6. Compliance Patterns
6.4 Defined patterns
- Conclusion by Tom.L concerning the possible pattern combination is
to combine the FC transistion pattern and mysticoms pattern into a
new CJTPAT.
- Final pattern should be finalised by next plenary.
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.
A- Tom.L to get reflector traffic moving with respect to this
issue.
- 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.)
10. Overall Verification of Jitter Budget
Was not able to be discussed due to time limitation.
A- Status and discussion to be driven on reflector (Anthony)
General :
- Up coming plenary and breaktime.
- March 12,13,14
- Monday morning should be allocated for breakout for comments and
jitter
XAUI Jitter Issue List
25th January 2001
Contents :
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
3. Transmit Jitter
3.1 Transmit data eye X1, X2 (difference)
3.2 Transmit 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.5 Test Equipment for Pattern Compliance testing
7. BER definition
8. Instantaneous Bit Shift
9. SONET SJ
10. Overall Verification of Jitter Budget
------------------------------------------------------------
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
A- Jitter low corner frequency, will result from White Paper
(Anthony)
A- Amplitude could result from FC White paper
A- Shelto to send some FIFO calculation out on reflector
A- Extention of lower frequency down to lower frequenc should be
done as comment to D2.1 (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
- 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 this document 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
- Technical Inputs : Ali, Tom.L, Mike.J, Anthony.S
- Rich.T shall prepare initial draft for next week´s editors
meeting
- Entire team shall meet at "Fiber channel meeting" in 2 weeks to
finalise contents of Annex.
- 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).
A- Section for Clause 47 to be written (Anthony, end week).
- This section should include the statement.
"During compliance testing of a XAUI channel using the
patterns described in Annex 48A, all channels in co-direction
should be active with the same pattern, the system providing a
natural skew of these channels, and all channels in the
contra-direction should be asynchronously active with valid
XAUI data."
- This section shall reference Annex 48A and the additional
methodology annex´s to be written, adding statement specific for
electrical testing of the XAUI interface.
------------------------------------------------------------
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 is to send 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.
------------------------------------------------------------
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.
4.4 FEXT/NEXT (Cross Talk)
Crosstalking effects consists of the following phenomina
- Amplitude to phase noise
- Direct DJ
- Supply crosstalk
- Other chip crosstalk
Currently defined as 0.4% of 800mV, or 0.07 TJ, and x.xx DJ.
Crosstalk could be a big issue as loosely coupled differential strip
lines are currently seen as the preferred solution for the XAUI
Channel. This leading to increased differential noise issues. Also
it is a concern that crosstalk at connectors could be high.
Common mode noise could be also be converted to DJ at the reciever.
Comment from Ali, that connector shall be the biggest form of
crosstalk.
A- Crosstalking specifications from typical connectors to be
collected from connector manufacturers by Rich and Ali.
A- Theoritical simulation of expected differential crosstalk to be
done (Anthony)
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.
A- Verification of max/min capability of RL required. Distance of
the first connectors from the driver should be verified for WC.
A- Jeff Cain and Tom to try and quantify RL requirements.
- See section 10. concerning overall verification.
------------------------------------------------------------
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
A- 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- Open issues concerning patterns to be closed (Rich.T, Mysticom,
Tom Lindsay, Tord)
- Conclusion by Tom.L concerning the possible pattern combination is
to combine the FC transistion pattern and mysticoms pattern into a
new CJTPAT.
- Final pattern should be finalised by next plenary.
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.
A- Tom.L to get reflector traffic moving with respect to this
issue.
- 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.)
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.
A- Input concerning types of equipment available (All)
------------------------------------------------------------
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
- Mysticom
- Jeff Porter
A- Status and discussion to be driven on reflector (Anthony)
Use of high pass filtering when assessing the transmit eye should be
used when assessing long patterns to account for tracking behavior.
Methods for inclusion of maximum group delay in simulations should
be assessed carefully.
Additional amplitude noise should not be forgotten about when
assessing the simulation results for receive eye.