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