RE: 8b/10b and EMI
Ed,
I don't think anyone has suggested that problem is emmissions disrupting the
computer system. The difficulty with respect to EMI from idle is passing
EMC testing. If the computer system was sensitive to the radiated noise, it
would probably take a pretty short sequence of bits to cause the disruption
(something on the order of 10s or 100s of bits). The worst case sequences
for
internal disruption will occur even with scrambled codes. Therefore, these
sequences must not cause interference with system operation.
On the other hand, EMI testing looks at power averaged over very long
periods
- millions of bits. Packets having data fields with a repeated pattern
such as a string of zeros or ones don't have a significant effect in this
time frame. Those I've consulted have said that the data sent for this
testing
needs to represent normal traffic. One is not required to pack packets with
the
worst case data pattern and send them repeatedly because one would not
expect
this in normal operation. Sending idle for extended periods is part of
normal
operation so one should pass the test sending idle. This is why the
emmissions
from a repetative idle pattern are an issue.
Regards,
Pat
-----Original Message-----
From: NetWorthTK@xxxxxxx [mailto:NetWorthTK@xxxxxxx]
Sent: Friday, March 17, 2000 7:40 PM
To: walker@xxxxxxxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: Re: 8b/10b and EMI
Dear Walker:
>
> The problem is also with repetitive input data patterns, such as all
> zeroes, or all ones. Such patterns are very common in computer data
> transmisssion.
The all "0" or "1" input data is different problem from the IDLE issue being
discussed here.
Regardless of line code, all PCB must be designed to sustain all "0" or all
"1" input signals simultaneously for all parallel data to shake up the whole
circuits to generate the maximum noise, crosstalk, radiation..etc, and still
meet all the requirements and BER. This is the first test every PCB
designer
will do to find out if all the design rules are correctly implemented. If a
PCB does not pass this most fundamental test, the board should not be
introduced for production.
>
> Were have you been hiding? :-).
>
> This is a big problem in the industry at 1G and 2.5G. The problem gets
> worse in proportion to the square of the frequency.
>
> If you are out in the field listening to the gossip, you'll find that
> many supply contracts have collapsed due to EMI problems at numerous
> companies. Of course, no sane company advertises when they have an EMI
> problem. This may be why you haven't heard about these issues.
>
I never heard that the EMI is so strong to collapse a computer system. Only
an intentionally designed EMI generator will have such power. Normally a
correctly designed equipment may have the EMI problem to cause increased
BER,
or nothing at all. However, it will cause interference to TV receivers,
wireless receivers or other radio receivers.
Some company has problem does not mean everyone has to have the same
problem.
EMI is a very complex issue which involves the source reduction and leaking
prevention of the whole circuit design inside a cabinet. The worst thing is
that you cannot measure it correctly, until it becomes the final product,
and
it requires a certified EMI lab. to provide an accurate data. If you got the
EMI problem, you may have to go through another development cycle to find
out
if the fix works. While in the development stage, your past success in the
EMI design counts a lot. The IDLE issue is only the very small part of the
whole EMI issue. I will never use IDLE as an excuse for any EMI design
deficiency.
You may be correct for mil-spec double-shielded enclosures, but such a
> requirement is not consistent with a low cost datacom standard.
>
In today's fiercely competitive, cost-effective market, no one can afford to
use the old technique, "solve the problem at any cost." Only the one who
knows how to solve the problem with the minimum cost will survive in the
market. It takes more than just engineering knowledge to do it.
> Best regards,
> --
> Rick Walker
>
>
Regards,
Ed Chang
NetWorth Technologies, Inc.