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