Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Annex 48A Jitter Test Patterns



******************  Virus Warning Message (on gemini2.ieee.org)

Found virus TROJ_NAVIDAD.E in file Emanuel.exe
The file is deleted.

If you have questions, contact virus-admin@xxxxxxxx

*********************************************************
  
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@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
> -----------------------------------------

******************  Virus Warning Message (on gemini2.ieee.org)

Emanuel.exe is removed from here because it contains a virus.

*********************************************************