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