| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
For now -
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.
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.
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.
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.
Hope this is useful.
Thanks, Tom Lindsay
Vixel
425/806-4074
Boaz Shahar wrote:
Rich,
In the last meeting (Jan 01), on Thursday, I presented simulation results
that show the following:1.A Random pattern creates a worst jitter then CJPAT for the XAUI compliance
channel proposed
2.The existence of a "Killer Pattern" (Called there "MystiCom Killer
Pattern") that generate much more jitter then the random patternThe presentation will be in the web soon.
Both the random pattern and killer pattern are XAUI valid pattern that may
occur during regular operation. It is true that Tom Lindsay explained that
when both devices are AC coupled, the CJPAT generates higher amount of
jitter (Our simulation was DC coupled). This may be true. Assuming that this
is right, the jitter pattern may be a composition of the two.Anyway, the subject is still under study, and I think its too early to
determine the pattern, especially due to the fact that in the XAUI Jitter
meeting we agree to further study it.Boaz
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Monday, January 15, 2001 11:12 AM
> To: HSSG
> Subject: Annex 48A Jitter Test Patterns
>
>
>
> Ladies and Gentlemen,
>
> This note contains the XGMII source for Jitter Test Patterns for the
> 10GBASE-X PHY. These patterns were approved by Task Force motion on
> Friday in Irvine. An updated copy of Annex 48A, including the
> proper CRC
> values, has been sent for upload to the P802.3ae web site as well. All
> patterns, with the exception the Continuous Jitter Tolerance Test
> Pattern (CJTPAT) in 48A.5, are exactly the same as or correspond to,
> Annex 36A patterns for 1000BASE-X. The CJTPAT is new and
> recommended for
> jitter testing by the MJS specification referenced in Annex 48A. The
> following are the open issues Annex 48A that I'm aware of. I'd
> appreciate the identification of any other issues as well as suggested
> remedies for open issues:
>
> 1) The applicability of these patterns to XAUI. My sense is that they
> are they are all directly applicable.
>
> 2) The number of times that the low/high data values are
> repeated in the
> CJTPAT frame may need to be adjusted to account for line rate
> differences between Fibre Channel and 10GBASE-LX4/XAUI. For
> example the
> low high values are repeated twice within a maximum length
> 802.3 frame.
> A note in Annex 48A addresses this point.
>
> 3) Are any other patterns required? I have heard that mixed frequency
> patterns which do not obey 8B/10B rules have been suggested.
> Personally,
> I don't believe that patterns worse than "worst case" patterns
> observable in a system environment need be specified. If additional
> patterns are required, please make those requirements known ASAP.
>
> 4) Are there any complaints about jitter compliance testing,
> effectiveness of patterns, availability of parts supporting patterns,
> etc. associated with 1000BASE-X? P802.3ae can benefit greatly form the
> experiences of 1000BASE-X users in this area since the
> 10GBASE-X PHY is
> based on 1000BASE-X. 1000BASE-X users with jitter testing experience
> should feel compelled to speak up now.
>
> 5) Annex 48A is now mandatory. This means that all 10GBASE-X PHY
> components must support all test patterns described in Annex 48A. It
> also means that Clauses 47, 48, 54 must all cross reference Annex 48A.
>
> Best Regards,
> Rich
>
> --
>
> Ben Brown wrote:
> >
> > Rich,
> >
> > Attached are the XGMII sources for the patterns. Please verify that
> > this is indeed the packets you want. The first column are
> the control
> > bits[3:0] in hex and the next column is the data bits[31:0] in hex
> > format. There are a few bytes of IPG and a preamble before and some
> > more IPG after the packet. The last row in both packets is the
> > CRC you asked for. Remember, in the annex, you might want to
> > write the bytes of the IPG in big endian format whereas they are
> > in little endian format in these files.
> >
> > Thanks,
> > Ben
> >
> > Rich Taborek wrote:
> > >
> > > Gentlemen,
> > >
> > > This note contains Annex 48A as presented to the
> 10GBASE-LX4 Working
> > > Group during Irvine, CA meetings of January 10-12.
> > >
> > > David Law: Please upload the file to the IEEE P802.3ae
> web site as an
> > > Irvine contribution. The title is: "Jitter test
> patterns". The author is
> > > me.
> > >
> > > Ben: Please calculate the CRC for the modified RPAT and
> JTPAT frames
> > > described in 48A.4 and 48A.5, respectively.
> > >
> > > Tom: Please take a look at the JTPAT patterns in 48A.5.
> The number of
> > > times that the low/high data values are repeated in the
> frame may need
> > > to be adjusted to account for line rate differences between Fibre
> > > Channel and 10GBASE-X. For example the low/high values above are
> > > repeated twice within a maximum length 802.3 frame. What's your
> > > suggestion for the exact length of each low/high pattern
> and how many
> > > times it should be repeated?
> > >
> > > --
> > >
> > > Best Regards,
> > > Rich
> > >
> > > -------------------------------------------------------
> > > Richard Taborek Sr. Phone: 408-845-6102
> > > Chief Technology Officer Cell: 408-832-3957
> > > nSerial Corporation Fax: 408-845-6114
> > > 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> > > Santa Clara, CA 95054 http://www.nSerial.com
> > >
> > >
> --------------------------------------------------------------
> ----------
> > > Name: anx48.pdf
> > > anx48.pdf Type: Acrobat (application/pdf)
> > > Encoding: base64
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > AMCC
> > 2 Commerce Park West
> > Suite 104
> > Bedford NH 03110
> > 603-641-9837 - Work
> > 603-491-0296 - Cell
> > 603-626-7455 - Fax
> > 603-798-4115 - Home Office
> > bbrown@xxxxxxxx