RE: [802.3ae] Proposed modifications to CJPAT
John,
There was a commnet made by Tom Lindsay against Annex38A in D3.2. The
comment basically said that a new jitter pattern should be proposed and
that John D'Ambrosia was working on one. Since no pattern was actually
proposed in the comment, the comment was rejected with the response to
have the commentor, or someone else, resubmit the comment at sponsor
ballot with a full pattern and some reason why it should be used instead
of or is better than CJPAT. This is definitely a technical change, since
in D3.3 we now state that CJPAT is to be used for receive jitter
compliance testing. If we add a new pattern or replace CJPAT, then I
think that's a technical change. So, to answer your question, John, there
is currently no open comment against CJPAT. I do not know if one has been
submitted against D3.3 yet.
Eric Lynskey
10 Gigabit Ethernet Consortium
UNH IOL
On Wed, 31 Oct 2001, DAmbrosia, John F wrote:
>
> 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
>