Re: Annex 48A Jitter Test Patterns
Guys - I need to take more time on this, but some initial comments:
1. The sequence of D11.7s and D20.7s is good in that it is valid D coding and can be sustained.
2. It may be more interesting to merge it into CJTPAT as the transition sections between the 7E's and the B5's rather than the transition bytes I have now. This will take a closer look - for example, in changing from low to high transition density, I would like to see no runs shorter than 3 before the run of 5 before the run of 1, etc. Putting the killer stuff in there should be tougher to tolerate, since the HPF action will accentuate the peak jitter.
3. I haven't run the payload portion of CJTPAT (let's call it JTPAT, since the "C" was used to indicate a compliant FC frame which included FC IDLEs, SOF, CRC, EOF, etc.) in the lab, so I can't confirm that its jitter is lower. It probably is.
4. I know the full CJTPAT (per FC) does include the same pk-pk jitter as K28.5's in the lab (DC coupled), although as I mentioned before, the frequency of occurence of the peak jitter is lower. Both disparities of K28.5's are included.
5. AC coupling in your setup - is this intended to the DR/1667 high pass filter? The DR/1667 HPF is supposed to represent the tracking of a PLL in the CDR, and I don't see that in your model.
Good stuff. Tom
Boaz Shahar wrote:
> Hi,
> The so called "MystiCom Killer Pattern" is similar to K+/K-, and brings the
> ISI to its extreme. The difference is that the "MystiCom Pattern" is a valid
> XAUI Pattern. The attached presentation describes the ISI Killer Packet and
> a comparison with the jitter created by the CJTPAT pattern. It also propose
> a combination between the two as the standard test pattern.
>
> Regards,
> Boaz
>
> > -----Original Message-----
> > From: Tom Lindsay [mailto:Tom.Lindsay@vixel.com]
> > Sent: Tuesday, January 16, 2001 5:56 AM
> > To: Ben Brown
> > Cc: 802.3ae
> > Subject: Re: Annex 48A Jitter Test Patterns
> >
> >
> > Ben - my first goal in all this is to explain the origin of
> > the original
> > CJTPAT and how I handled it in Fibre Channel applications. I
> > am not yet
> > sufficiently familiar with XAUI and its frame structure to know how it
> > should be put into good use. I hope that someone else can
> > help me with this,
> > or perhaps it can be a topic for the next XAUI jitter con call.
> >
> > Tom
> >
> > 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@earthlink.net]
> > > > >> > 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@nSerial.com
> > > > >> > > > 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@amcc.com
> > > > >>
> > > > >
> > >
> > > --
> > > -----------------------------------------
> > > 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@amcc.com
> > > -----------------------------------------
> >
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Name: testpat.ppt
> testpat.ppt Type: Microsoft PowerPoint Show (application/vnd.ms-powerpoint)
> Encoding: base64
> Download Status: Not downloaded with message