Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] Proposed modifications to CJPAT




Eric, John -

I agree with Eric's view.

Also, I have no intention of submitting this as a comment against D3.3,
which is a recirculation ballot. I only put the proposals onto the
reflector to begin discussion in case we want to make a change later.

Tom

-----Original Message-----
From: Eric R. Lynskey [mailto:elynskey@mars.iol.unh.edu]
Sent: Thursday, November 01, 2001 7:49 AM
To: DAmbrosia, John F
Cc: Tim Warland; Lindsay, Tom; stds-802-3-hssg@ieee.org; Kesling, Dawson
W
Subject: 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.p
df)
> 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@tycoelectronics.com
> 
> 
> 
> 
> -----Original Message-----
> From: Tim Warland [mailto:twarland@mail.quaketech.com]
> Sent: Tuesday, October 30, 2001 5:24 PM
> To: Tom Lindsay
> Cc: stds-802-3-hssg@ieee.org
> 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
>