RE: CRPAT / CJPAT Pattern Question
Folks - I think the concept John and Michael have gotten to has a lot of
value:
Pat 1A Pat 1B Pat 1C Pat 1D
Lane A + - - -
Lane B - + - -
Lane C - - + -
Lane D - - - +
However, before I comment more on how we could build this up and control
disparity, I have a higher level question (John's last response
triggered this...).
48A presently includes 3 short patterns and 2 "complete" patterns. Are
any recommendations given in clauses 47 or 53 for when/where/why these
patterns are used?
The is an "objectives" type of question. I believe the most important
requirement for the patterns is that they be used as a industry-common
tool for compliance testing at the highest level of integration for that
interface. As such, compliance testing patterns should be packet-based.
Obviously they must also provide the appropriate stress to excite
mechanisms that can degrade performance (such as crosstalk).
Where I am going with this, is that compliance testing is different than
diagnostic testing. Compliance testing needs a pattern by which jitter,
eye mask, and all other parameters in the standard are tested in an
overall sense. Michael - your ideas are very good, but I feel that
determining which channel the crosstalk is coming from falls to a
diagnostic level possibly outside of the scope of a standard.
Fibre Channel went through this beginning with the MJS project. The
approach was to move away from K28.7s, D10.2s and K28.5s and towards
CRPAT, CJTPAT, etc. For clauses 47 & 53, I recommend CRPAT and CJPAT be
specified for compliance testing (again, I'm leaving the build-up John
and Michael's ideas for later). I have no trouble leaving the 3 short
patterns in there as useful for diagnostics, but make it clear they are
not appropriate for compliance.
So, Rich and Dawson - what do you think?
Tom
-----Original Message-----
From: DAmbrosia, John F [mailto:john.dambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, June 14, 2001 9:50 AM
To: 'Michael Debie'; 'Serial PMD reflector (E-mail)'
Subject: RE: CRPAT / CJPAT Pattern Question
Michael,
I think you and i are on the same wavelength. My earlier proposal was
intended to use the proposed CJPAT or CRPAT and just invert one of them
on a
target channel. I suggest this to minimize the amount of new
discussion, so
things can keep moving.
Dawson/Rich/Anthony, what do you think?
John
-----Original Message-----
From: Michael Debie [mailto:mdebie@xxxxxxxxxxxxx]
Sent: Thursday, June 14, 2001 12:47 PM
To: DAmbrosia, John F; Michael Debie; 'Serial PMD reflector (E-mail)'
Subject: RE: CRPAT / CJPAT Pattern Question
John,
Absolutely agree. I was just simplifying my description to one lane,
but, I
assumed we would test each lane individually. As far as the pattern
selection is concerned, the use of different patterns on each lane
allows us
to see the contribution each of the other lanes has on cross talk noise.
For example, suppose Lane 1 was driving a /5 clock like pattern
(1111100000)
the FFT of the jitter on the Lane under test would show a spectral line
at
Fc/10 and the amplitude of the spectral line would be the pk-pk impact
on DJ
that Lane 1 has on the Lane Under Test (LUT?). We could set up the other
3
lanes with varying degrees of clock like patterns and quickly estimate
each
lanes contribution to crosstalk on the LUT. We could perform this test
on
all 4 lanes to measure crosstalk contribution. It would also be
interesting
to sweep through several clock like frequencies on the non tested lanes
to
quantify the impact of crosstalk as a function of instantaneous
frequency.
The test in which we apply the same pattern on all of the non tested
lanes
will tell us how the crosstalk components combine.
Regards,
Michael
-----Original Message-----
From: DAmbrosia, John F [mailto:john.dambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, June 14, 2001 9:11 AM
To: 'Michael Debie'; 'Serial PMD reflector (E-mail)'
Subject: RE: CRPAT / CJPAT Pattern Question
Michael,
I think your second proposal makes more sense, but i think it would need
to
go one step further. I think we should cycle which lane is the
"different"
lane like this-
Pat 1A Pat 1B Pat 1C Pat 1D
Lane A + - - -
Lane B - + - -
Lane C - - + -
Lane D - - - +
Where the "+" lane would be the pattern, and the "-" would be the
compliment. Thus, all channels get examined. If only 1 lane is tested,
then the test is specific to the implemenation, where if all lanes in a
channel get examined, then the performance of the channel is fully
examined
rather than 1/4 of it.
John
-----Original Message-----
From: Michael Debie [mailto:mdebie@xxxxxxxxxxxxx]
Sent: Wednesday, June 13, 2001 5:41 PM
To: DAmbrosia, John F
Subject: RE: CRPAT / CJPAT Pattern Question
John,
A good diagnostic for cross talk would be to place different frequency
clock
like patterns on all of the lanes. This could tell us the amplitude of
cross talk per other lane and where it comes from. Also, if we run the
same
patterns on three lanes and one lane different, we could see how the
other
three lanes combine to effect cross talk on the lane under test.
Regards,
m
-----Original Message-----
From: DAmbrosia, John F [mailto:john.dambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, June 13, 2001 4:21 PM
To: Serial PMD reflector (E-mail)
Subject: CRPAT / CJPAT Pattern Question
Everyone,
The 10GEA XAUI Interoperability Group met this week, and were discussing
the
use of the CRPAT / CJPAT patterns for its testing. A general
observation
was that the same data pattern appear on all 4 lanes synchronously,
which
means crosstalk is not really being testing, which was probably being
accounted for by connector crosstalk budget of 4%. Tyco presented data
http://grouper.ieee.org/groups/802/3/ae/public/may01/dambrosia_2_0501.pd
f
that showed that crosstalk, which resulted from signals switching
in-phase
(i.e. high to low or low to high), could actually improve the overall
response of the system. Thus, the resultant eye is improved and would
be
best case, and not even nominal (all adjacent channels quiet).
Obviously, there are a lot of system variables that come into account
when
considering crosstalk, but it would seem that we could improve the
harshness
of these patterns by not making all 4 channels have the same data
patterns.
John D'Ambrosia
Manager, Semiconductor Relations
Tyco Electronics Corporation
Tel. 717.986.5692
Mobile 717.979.9679
email - john.dambrosia@xxxxxxxxxxxxxxxxxxx