RE: Annex 48A Jitter Test Patterns
Tom,
I think we can create a CJTPAT-type pattern that is compliant on all
levels (coding, protocol, packet size etc.) without giving up test
coverage or control over disparity. By running tests for CDR upsets
after adaptation to high and low density "training" on different XAUI
lanes we can get around the packet size limitations while still having
the disparity flip.
Outline:
0 1 2 3
~180 x loDens(7E) loDens(7E) hiDens(B5) hiDens(B5)
: : : :
a few lFchars lFchars hFchars hFchars
~180 x loDens(7E) loDens(7E) hiDens(B5) hiDens(B5)
: : : :
a few l-chars l-chars h-chars h-chars
lFchars denotes characters that are tough as successors to a long series
of characters with low transition density. This set must flip the
disparity.
hFchars denotes characters that are tough as successors to a long series
of characters with high transition density. This set must flip the
disparity.
The successor characters at the end of the packet can be chosen without
concern for the disparity,
The maximum packet size should be utilized. For CDR settling the three
time constants should be sufficient, but for putting AC-coupling to the
test, we should energize the lowest parts of the spectrum as much as
possible.
If all lanes must be subjected to both high and low density sustained
patterns, the CJTPAT-type pattern will require more than one packet.
For the opposite direction XAUI output links a list of allowed patterns
should be agreed upon. For a start: Idle, Various error codes, This
CJTPAT....
These XAUI outputs should have 100 ohm terminations.
Best regards Tord.
-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Tuesday, January 16, 2001 22:15
To: 802.3ae
Subject: Re: Annex 48A Jitter Test Patterns
Joel,
I think quite a lot of people will have quite a lot to say
about sending packets larger than 1518/1522, though many
implementations support longer packet sizes. These were the
2 sections that I found when parsing the standard for
maxFrameSize. I assumed it would be spelled out a bit more
plain but I think this is sufficient.
3.2.7
"The maximum possible size of the data field is
maxFrameSize - (2 x addressSize + 48)/8 octets."
4.2.4.2.1
"a) Maximum Frame Size. The receiving CSMA/CD sublayer
is not required to enforce the frame size limit, but it
is allowed to truncate frames longer than maxFrameSize
octets and report this event as an (implementation-
dependent) error."
Ben
Joel Goergen wrote:
>
> Ben
>
> This has come up before in logic track discussions, but the way I read
the
> max packet length, there is nothing in the standard for 10gig that
says a
> longer packet is 'not' legal. And there is no mechanism I am aware of
that
> prevents a longer packet from coming through to the mac.
>
> Take care
> Joel
> -------------------
>
> Ben Brown wrote:
>
> > Tom,
> >
> > I trust that when you provide this pattern, it is intended to
> > occur on each lane. Is that correct? The problem is that would
> > result in a 1828 byte packet with FCS. This is beyond ethernet's
> > max packet size. Is there a way to trim it down? Could you
> > simply send the first half of the packet only but repeat it
> > often? IPGs will sometimes flip disparity and sometimes leave
> > it alone. Therefore, sometimes the packet will start with the
> > right disparity and other times it will start with the wrong
> > disparity. Either way, the packet is short enough to be a legal
> > length.
> >
> > Ben
> >
> > Tom Lindsay wrote:
> > >
> > > Rich - I mentioned a disparity "flipper" I used before. This
allowed
> > > us to build a payload which was roughly twice as long, but the 2nd
> > > half of the payload began with opposing disparity from the 1st
half.
> > > In this case, half the pattern was the desired disparity, but
other
> > > was not. The half that was not still contains the low frequency
> > > transition density changes, but not the abrupt phase jumps.
> > >
> > > Using the previous pattern list, modify the 1st half to be:
> > > 167 7E's
> > > 1 74
> > > 1 7E
> > > 1 AB
> > > 51 B5's
> > > 1 5E
> > > 1 4A
> > > 5 7E's
> > > The 2nd half, following immediately, would be:
> > > 1 71
> > > 166 7E's
> > > 1 74
> > > 1 7E
> > > 1 AB
> > > 51 B5's
> > > 1 5E
> > > 1 4A
> > > 5 7E's
> > > The 71 is the "flipper".
> > >
> > > Tom
> > >
> > > Tom Lindsay wrote:
> > >
> > > > Folks - I would like to post a simple spreadsheet to the 10GE
site,
> > > > but you'll have to tell me how to do it first... The spreadsheet
> > > > provides some analysis on CJTPAT (which stands for Compliant
Jitter
> > > > Tolerance Test Pattern in Fibre Channel). If we understand how
this
> > > > pattern was developed, it should be easier to adapt it to
Ethernet
> > > > needs. I have a lot of additional 8B10B analysis, but it doesn't
> > > > seem appropriate for this discussion.
> > > >
> > > > 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
pattern
> > > >>
> > > >> The 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
> > > >>
> > > >
> >
> > --
> > -----------------------------------------
> > 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
> > -----------------------------------------
>
> --
> Joel Goergen
> Force10 Networks
> 1440 McCarthy blvd
> Milpitas, Ca, 95035
>
> Email: joel@xxxxxxxxxxxxxxxxxxx
> Direct: (408) 571-3694
> Cell: (612) 670-5930
> Fax: (408) 571-3550
--
-----------------------------------------
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
-----------------------------------------