RE: [802.3ae] Proposed modifications to CJPAT - round 3
Did you discuss the option of rotating each of the lanes of CJPAT? (Lane 0
not rotated, lane 1 by quarter of a frame etc.)
> -----Original Message-----
> From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, November 20, 2001 4:20 AM
> To: THALER,PAT (A-Roseville,ex1); Mike Jenkins
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3
>
>
>
> Pat - see within. Thanks, Tom.
>
> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Monday, November 19, 2001 5:25 PM
> To: Lindsay, Tom; Mike Jenkins
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3
>
>
> Tom and Mike,
>
> The idea of CJPAT was to have a pattern that could be sent
> and received
> by a
> MAC. That is why the pattern is encapsulated in a packet. The only way
> to
> control running disparity would be to have a test mode that is sourced
> by
> the PHY which would be a rather significant feature change at this
> point.
> Even then, it gets a bit tricky. If one has a transceiver where a full
> X-PCS
> and XGXS is implemented, then that would be producing its own idle and
> would
> need to source the pattern while if the transceiver had just a simple
> retimer between the MDI and the XAUI, the pattern would need
> to be sent
> into
> it.
>
> >>TAL - as I expected. Thanks, I guess... Sounds like true disparity
> control is not possible.
>
> Some alternatives without controlling starting disparity:
>
> Build a new stress pattern using only disparity neutral codes - those
> codes
> that are the same in both disparity columns. I'm not
> convinced one could
> build as good a pattern this way. The high density part of the pattern
> uses
> a disparity neutral code already but the low density doesn't and there
> may
> not be a 3 transition disparity neutral code (and I don't have time to
> look
> at the moment). The EB and F4 are also not neutral.
>
> >>TAL - you are right, the pattern would not be as good. I have looked
> into this already, and at this point would rather stay along the lines
> of CJTPAT since it is "proven" in Fibre channel. By the way, Fibre
> channel controls frame disparity via the end-of-frame - one of two
> values is chosen based on incoming disparity such that the ending
> disparity is always negative.
>
> There are two repeats of the pattern in the CJPAT packet. If one made
> the
> low density pattern repeat for an odd number of bytes per lane, one
> would
> test both disparities on the lane during one packet. Changing the
> duration
> of the low density pattern to 524 bytes would accomplish this. This
> still
> would mean the crosstalk is somewhat unknown since the starting
> disparity of
> each of the lanes is unknown. F4 and EB in the two disparities are not
> inverses of each other but the bulk of the pattern (B5 and
> 7E) is either
> the
> same or inverted for the two disparities so the frequency content and
> therefore the crosstalk shouldn't be changed much based on the
> disparity.
>
> >>TAL - the two repeats (in Option 1 only...) are there precisely for
> disparity "inversion" - each repeat in each lane is the
> opposite of the
> other repeat in each lane. This was accomplished with selection of the
> number of 7Es and the occasional AB bytes. I think Option 2,
> which does
> NOT repeat per packet, is dead because of the inability to precisely
> control the IGP and therefore disparity - it could get
> "stuck" in either
> the correct (stressful) or incorrect (less stressful) disparity.
>
> >>TAL - by the way, I believe that even the less stressful portion of
> the patterns will still be useful for general randomization, which may
> flush out other unexpected issues or weaknesses. Time will tell.
>
> Even if one doesn't change the pattern, the idle is
> randomized AKR which
> will randomize the starting state of a lane at the start of the packet
> so
> successive repeats of the CJPAT packet should test both polarities of
> the
> pattern on each lane. (Since the same code is sent on each lane during
> idle
> and the pattern, the CRC for the current packet is composed of 4
> non-diaparity flipping codes and the start packet sequence is
> non-disparity
> flipping, the lanes will keep a constant disparity with
> respect to each
> other when CJPAT packets alternate with idles.)
>
> >>TAL - I agree, but I still feel there is strong value in
> shifting the
> contents of two of the lanes around. This is deterministic and
> independent of disparity and probably the most important part of the
> recommendation.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> Sent: Monday, November 19, 2001 2:34 PM
> To: Mike Jenkins
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3
>
>
> fAJMYSF10643
> Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> Precedence: bulk
> X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> X-Listname: stds-802-3-hssg
> X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
>
>
> Hi Mike -
>
> As always, you understand all quite well.
>
> I do not know what control there can be in disparity. In terms of the
> document, I would like to add a statement along the lines of
> "For jitter
> and other compliance testing with this pattern, it is recommended that
> all lanes begin with negative running disparity and that the IPG be
> strictly controlled as shown."
>
> Since this is a test mode, it should be possible to "jump" disparity
> without upsetting too much. I suspect, however, that most
> folks probably
> don't have that level of control in their silicon?? (that is a
> question).
>
> If running disparity at the start cannot be controlled, and there is
> preceding traffic that sets them differently from eachother, then the
> patterns will still work, but the desired disparity phasing obviously
> will not be achieved. This is not a killer.
>
> Also, if the IPG is not controlled (to |T||A||R| and back to the start
> (where |T| is comprised of /K//K//K//T/), then disparity will not be
> strictly controlled from one repetition to the next. Can we
> expect that
> level of control?? (that is another question). If not, then I would
> recommend Option 1.
>
> Getting back to probabilities of disparity - for crosstalk
> and EMI, the
> real question is how the 4 lanes match (to lane 3 for example). So if
> disparity is truly random, then it comes down to 1/(2**3) (12.5%).
>
> The more important change in the recommended pattern is the
> shifting of
> high and low transition density cores within each lane - that
> is lanes 2
> & 0 are shifted from what they are in the pattern presently in D3.4.
> This change will have the most profound effect and is
> independent of the
> disaparity and IPG issues.
>
> Tom
>
>
> -----Original Message-----
> From: Mike Jenkins [mailto:jenkins@xxxxxxxx]
> Sent: Monday, November 19, 2001 1:50 PM
> To: Lindsay, Tom
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: [802.3ae] Proposed modifications to CJPAT - round 3
>
>
> Tom,
>
> First of all, thanks for your ongoing efforts to develop the
> best test pattern here.
>
> Please let me ask a couple questions to make sure I understand
> the issues (since I can't do 8B10B encoding in my head). Where
> I'm coming from is the need to understand what deterministic
> 10-bit pattern(s) would constitute the patterns you propose.
> At the serdes level without an 8B10B encode/decode function,
> we need to test with fixed, pre-coded 10-bit patterns.
>
> So, if I understand correctly, each lane is assumed to have a
> random starting disparity, yielding 2**4 possible starting
> conditions. "Disparity flipping" bytes switch the disparity
> in mid-pattern (option 1) or between consecutive patterns
> (option 2). Hence, when viewed on the 10-bit side, options 1
> and 2 are almost identical, with a few more packet header
> characters in the middle of the option 2 repeating 10-bit pattern.
> In either case, the repeating 10-bit pattern in each lane is
> approximately 380 10-bit characters long. Also, there are 2**4
> possible valid 10-bit repeating CJPAT patterns on the 4 lanes.
>
> I'd appreciate it if you could point out what I might have got
> wrong in my understanding. (Also, at least one example of the
> proposed pattern in 10-bit code would be quite useful.)
>
> Thanks,
> Mike
>
>
> Tom Lindsay wrote:
> >
> > All -
> >
> > As you may have seen on the reflector, I am proposing
> changes to CJPAT
> in
> > Annex
> > 48A. There were responses from my previous postings that raised some
> > questions and confusion, so below, I will try to explain why I am
> doing
> > this. I plan to submit (one of) these as a comment in
> sponsor ballot.
> >
> > CJTPAT, from Fibre Channel, was designed as a
> single-channel tolerance
> > pattern to stress the clock and data recovery process. It
> also turned
> out to
> > be a useful jitter test pattern for general use. These
> properties were
> > carried over to each lane of Ethernet's CJPAT.
> >
> > CJPAT was "engineered" with a highly improbable bit
> sequence. The most
> > stressful feature in the pattern occcurs once per
> repitition. Assuming
> > completely random data, I estimate the probability of this type of
> feature
> > to be less than 1e-100. However, since 8B10B is
> deterministic, and the
> > sequence is legitimate, it is arguably acceptable for
> reasonable worst
> case
> > testing.
> >
> > Hence, CJPAT was adopted, and without further thought, replicated on
> all
> > 4-lanes. This provides simultaneous jitter testing of all 4 lanes,
> however,
> > they carry identical and 100% in-phased bit sequences. This is quite
> > unnatural, since In normal random traffic, <1% of the columns will
> have
> > edges switching in phase (across the 4 lanes).
> >
> > Three questions:
> > 1. Is the replicated pattern still within the bounds of reasonable
> worst
> > case? Again assuming random data, we're now below a probability of
> 1e-400,
> > which is clearly not justifiable.
> > 2. Is this what we want for crosstalk? Testing of real
> hardware showed
> that
> > the simple replication led to improved signal properties (when
> compared to
> > single-lane only traffic). The improved signal properties
> were caused
> by
> > constructive or supportive effects of in-phase crosstalk.
> > 3. Is this what we want for EMI? EMI was not tested, but the same
> mechanisms
> > would lead to higher emissions than if the lanes were not
> synchronous.
> >
> > I believe that these effects are artificial and must be addressed:
> > a. The improved signal properties due to crosstalk are a concern
> because a
> > system that appears compliant with this pattern may not be able to
> pass
> > compliance with normal traffic. In fact, it would be possible to
> > intentionally design crosstalk in a way that helps a unit pass
> compliance.
> > Conversely, it is possible that the crosstalk would be destructive,
> failing
> > an otherwise compliant system with normal traffic.
> > b. If the pattern is used for EMI testing, the in-phase lanes may
> cause
> > compliance failure in a system that could pass with more normal
> traffic. The
> > present pattern is absurdly unrealistic.
> >
> > The proposed patterns have the following properties:
> > 1. They retain the exact per-lane jitter properties of CJPAT.
> > 2. They jumble/scramble the relative phases of the 4 lanes
> to be much
> more
> > realistic. This is done via lane staggering and attempted disparity
> control,
> > and should greatly eliminate the effects of crosstalk and
> reduce EMI.
> In
> > addition, it should be impossible to optimize a design around the
> pattern.
> >
> > The latest proposals (11/16) are included again below.
> >
> > Thanks,
> > Tom Lindsay
> > Stratos
> > 425-672-8035 x105
> >
> > *************
> > OPTION 1:
> > This option keeps the present CJPAT core in lanes 3 and 1,
> EXCEPT that
> they
> > attempt to run with opposing disparity from each other due to an
> inserted
> > disparity flipper in the first byte in lane 1 (an inserted byte in
> lane 3
> > does not flip disparity). I say "attempt" because
> (relative) starting
> > disparities can never be assured. The 2 cores will be
> opposing only if
> > disparities coming into the start of the pattern are the same, AND
> there is
> > nothing transmitted between repetitions of the pattern that
> subsequently
> > shifts their relative disparity. Note - if starting disparities are
> not
> > controlled to match as hoped, the disparity bytes causes the 2 lanes
> to
> > revert to synchronous transmission.
> >
> > Lanes 3 and 1 begin with low transition density then switch to high
> > transition density. For option 1, this order is reversed in lanes 2
> and 0 -
> > lanes 2 and 0 begin with high transition density then switch to low
> > transition density. Therefore, lane pairs 3-1 and 2-0 will not be
> > synchronous, regardless of disparities. Opposing disparity is also
> attempted
> > between lanes 2 and 0 with a disparity flipper in lane 0.
> >
> > Note that CJPAT's per-lane jitter properties require
> specific starting
> > disparity in each. Since starting disparities cannot be
> assured, CJPAT
> was
> > designed so that all lanes switch their disparities 1/2 way through
> the
> > pattern, otherwise repeating the first half. Half of each lane's
> pattern
> > will have the appropriate jitter properties; the other half will not
> (but
> > will still provide useful "randomization". This characteristic of
> CJPAT has
> > not changed with proposed Option 1.
> >
> > 3 2 1 0 lane#
> >
> > 4x data # of column repeats
> > 55 00 07 07 1 disparity control
> > 7E B5 7E B5 40
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E 7E 7E 7E 84
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > AB 7E AB 7E 1
> > B5 7E B5 7E 40
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 AB F4 AB 1
> > 7E B5 7E B5 40 start 2nd half of pattern
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E 7E 7E 7E 84
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > AB 7E AB 7E 1
> > B5 7E B5 7E 40
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 AB F4 AB 1
> > DD 09 AE 5B 1 CRC
> >
> > OPTION 2:
> > Option 2 is ~1/2 the length of option 1. This is accomplished by
> selecting
> > disparity flipping bytes and resulting CRC in a manner that returns
> the
> > opposite starting disparities to the beginning of the pattern. Each
> time the
> > pattern runs, each lane alternates disparity so that like option 1,
> half the
> > time each lane achieves the desired jitter properties, and the other
> half of
> > the time it does not.
> >
> > Note that this assumes that the pattern repeats with an odd
> number of
> IPG
> > rows as shown in 802.3ae draft 3.3 (12 bytes). If the length of the
> IPG is
> > continually an even number of rows, then the disparity will
> not flip,
> and
> > the pattern could get "stuck" with either the correct of incorrect
> jitter
> > properties.
> >
> > Again, lanes 2 and 0 reverse the sequence of high and low transition
> density
> > with lanes 3 and 1. Also like option 1, lanes 3 and 1
> attempt relative
> > opposing disparity, and lanes 2 and 0 attempt relative opposing
> disparity.
> >
> > 3 2 1 0 lane#
> >
> > 4x data # of column repeats
> > 55 55 07 07 1 disparity control
> > 7E B5 7E B5 40
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E EB 7E EB 1
> > 7E F4 7E F4 1
> > 7E 7E 7E 7E 84
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > EB 7E EB 7E 1
> > F4 7E F4 7E 1
> > AB 7E AB 7E 1
> > B5 7E B5 7E 40
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 EB F4 EB 1
> > EB F4 EB F4 1
> > F4 AB F4 AB 1
> > CC 08 09 CA 1 CRC
> >
> > In both options 1 and 2, START/PREAMBLE/SFD and IPG remain identical
> to what
> > are shown in 802.3ae D3.3. ALL data here is consistently shown in
> little
> > endian format.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Jenkins Phone: 408.433.7901 _____
> LSI Logic Corp, ms/G715 Fax: 408.433.7495 LSI|LOGIC| (R)
> 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
> Milpitas, CA 95035 http://www.lsilogic.com |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
> ----- End Included Message -----
>