RE: [802.3ae] Proposed modifications to CJPAT
Tim,
The recommendations that I had suggested had nothing to do with EMC.
The issue with CJPAT is that there is a liklihood that the same pattern
would be running on all 4 lanes. I believe Tom had estimated a 12% chance
of this happening. THe problem with this is that if all lanes are switching
via the same pattern then, the channel response of any one of the four given
lanes may be improved as a result of potential crosstalk, thus there is an
artificial improvement to the channel. Due to system implementations, it is
difficult to assess this potential. Tyco had presented some simulations in
May
(http://grouper.ieee.org/groups/802/3/ae/public/may01/dambrosia_2_0501.pdf)
that illustrated this potential when just considering potential crosstalk in
the connector and its PWB footprint.
I believe you are misinterpretting what Tom and I (mostly Tom, given him the
credit for all his efforts) are trying to accomplish. We are not trying to
inject crosstalk into the testing. Instead, we are trying to prevent
crosstalk that would result from a specific test pattern from having a
positive influence on the testing. Tom's suggested pattern is just trying
to reduce the liklihood of all lanes switching with the same pattern.
I understand your comments about CJPAT, and the logic to implement it. That
is why we tried to stick to CJPAT, and not come up with a suggested pattern
that would actually the crosstalk aspects. As you stated, CJPAT was
intended to stress the jitter of the CDR. It is really a pattern for a
given channel, and the issue comes when you then apply that pattern to all
of the lanes, and the synergistic impact of it.
Finally, Tom and I have been working on this issue for some time, and I
believe the initial request was per Dawson. Dawson, could you comment on
whether there is an open comment regarding the crosstalk issue that Tom and
I have been addressing. Considering the limited liklihood of the same
pattern running on all 4 lanes, perhaps it is not that significant an issue.
We are merely trying to improve CJPAT as much as possible while making
minimum changes.
John D'Ambrosia
Manager, Semiconductor Relations
Tyco Electronics Corporation
Tel. 717.986.5692
Mobile 717.979.9679
email - john.dambrosia@xxxxxxxxxxxxxxxxxxx
-----Original Message-----
From: Tim Warland [mailto:twarland@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, October 30, 2001 5:24 PM
To: Tom Lindsay
Cc: stds-802-3-hssg@xxxxxxxx
Subject: Re: [802.3ae] Proposed modifications to CJPAT
Tom Lindsay wrote:
> Folks - Per John D'Ambrosia's work on EMI and crosstalk testing for XAUI,
it was recommended that
> CJPAT be modified to avoid transmitting synchronous patterns in all 4
lanes. I present 2 options
> for resolving this below.
I have to oppose this recommendation. One of the fundamental advantages
of the XAUI bus is that it has low EMI (due to the coding scheme). The
notion of developing a test to generate more EMI appears to contradict
this premise.
Secondly, the jitter test patterns were developed to allow testing of XAUI
modules in isolation from the system environment. Tests which over-
exercise the crosstalk and EMI would test the motherboard trace routing
more than the XAUI module in isolation. In other words, a great module
on a poorly routed board would be detected as a failing module - resulting
in finger pointing.
Thirdly, the generation of CJPAT requires fairly complex logic. The
requirement
to generate four "correctly aligned" patterns un-necessarily complicates the
logic - requiring more gates and more power.
Lastly, the deadline for technical changes has passed.
The CJPAT was originally created to induce failure modes in the receiver
CDR. To that end, the pattern is good. The amount of effort required to
generate this new pattern is more than the failures it will induce.
--
Tim Warland P. Eng.
Applications Engineer
Quake Technologies (613)270-8113 ext 2311
Success is a journey, not a destination