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

RE: [802.3ae] Proposed modifications to CJPAT - round 3




Pat - I agree with everything you say, although at some point the
probability of something happening even with a deterministic code gets
beyond the point of reason. I think the new proposal is still fine.

As far as EMI, I agree that we don't want to get into mandating a
pattern. My thoughts were more along the line that some folks may try to
use this pattern just because "it's there", and so I wanted to mix it up
a bit.

Regarding your other email suggesting some other designs to vary the
lanes, yes there are options, but I personally don't have any more time
and want to be done. For example, instead of D30.3s (7Es), alternating
D28.7s and D3.7s will rotate the phasing, but work only under one
disparity and complicate the documentation considerably. D7.7s also
work, but their transition into the scrambled sections don't work as
well. D10.2s are out of phase with D21.5s but again don't transition as
well, etc., etc.

Aside from disparity, the new proposal is still much better for
scrambling bit alignment, retains the CJPAT properties in all lanes, is
a single pattern, and does not require any more of my time...

Thanks, Tom


-----Original Message-----
From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
Sent: Tuesday, November 20, 2001 10:58 AM
To: pat_thaler@xxxxxxxxxxx; Lindsay, Tom; jenkins@xxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: [802.3ae] Proposed modifications to CJPAT - round 3


Tom

I wanted to address some of your earler questions so I've snipped them
out
of the string.

On the probablility of a given test pattern. 

When testing a scrambled system it is reasonable to consider the
probability
of a particular pattern because the next time the same data is sent the
pattern will be different. 

With a deterministic encoding such as the 8B/10B, we need to test that
the
worst case pattern can be sent. Even if a particular packet has a low
probability worst case pattern, it will have that pattern every time it
is
sent. That pattern must be able to get through the system. Also, for the
deterministic encodings, there is less variety (smaller standard
deviation)
across the code. For instance, 8B/10B codes will produce transition
densities between 3 and 10 transitions per 10 bits, they have a maximum
run
of 5 and negligable disparity at any given moment. What this means is
that
there is much less distance between a worst case pattern and an average
pattern. There will be a lot of near worst case data patterns.
Therefore,
testing that the channel will pass a "low probability" worst case
pattern is
reasonable.

On EMI testing: 

No repeating data packet should be used for testing EMI. My
understanding is
that EMI testing is to be done in reasonably normal operating
conditions.
Sending a constant stream of repeating packets would not be a normal
operating condition. 

Any repeating pattern concentrates energy at the frequency of the repeat
rate and its harmonics. We know from experience of EMI testing on 1 Gig
products which have a repeating idle pattern that this made it extremely
difficult to pass EMI regulations. That is why we developed the
randomized
idle for 10 Gig. What was difficult at 1 Gig would become impossible as
we
moved up in frequency.

When one sends a stream of CJPAT packets, one is sending 7E more than
half
the time in a repeating pattern. This will produce a lot of spikiness in
the
power spectrum. It wouldn't be a normal operating condition and I
wouldn't
expect it to pass EMI.

Because the EMI tests measure a peak average power rather than an
instantaneous power, I would not expect synchronization to produce much
of a
difference in the test result. 

Because EMI testing is the province of regulatory bodies, we have not
specified test patterns for EMI testing in the past and I don't think we
should start. It is a fairly complex area and I don't think we have the
right membership.

Regards,
Pat

Tom Lindsay wrote:
  <snip>
>
> 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.
>