Re: New thread on EMI
Dear Ed,
In response to your question about 8b/10b IDLE & clocking below...
I haven't seen any proposal for 8b/10b in this context (XAUI, in particular)
that requires a clock at the baud rate (3.125Gbaud). In that case,
the repetitive IDLEs (even with alternating polarity) become the dominant
source of high-frequency EMI.
Best regards,
Tom Truman
Lucent Technologies / Bell Labs
Edward Chang wrote:
>
> Hi Joel:
>
> I will be more than glad to share my thought with you. After all, we all
> share knowledge each other anyway.
>
> The worst signals are always those clocks and synchronous data from their
> associated synchronous circuits. In GbE, for example, there are serial
> clock, transmit byte clock, receive byte clock, I/O clock, and other logic
> clocks. Those clocks are high frequency with sharp rise/fall edges (high
> frequency components). When a synchronous clock switches, all other
> associated circuits also switch to provide multiple synchronous noises,
> which enhance the EMI amplitude many times more than a single signal --IDLE.
>
> Especially, if all parallel bits (for example, 64 bit-wide PCI bus) switch
> the same data pattern (all "0", and all "1') at the same time, the EMI
> radiation level will far exceed any EMI level generated by a single signal.
> The occasional IDLE signal is much weaker than those clocks and their
> associated synchronous signals.
>
> The IDLE signal in the 8B/10B code is alternately reversing the polarity
> every 10 bits as any other 8B/10B data pattern does. The only unique thing
> about IDLE is "REPETITIVE" during the idle period. If "repetitive" is the
> reason for EMI concern, then how are we going to deal with clocks which are
> REPETITIVE all the time, and have much stronger EMI level.
>
> For an EMI design, there are always two design objectives; namely, reduce
> source strength and prevent leaking-out. In other words, we can not make
> those clock and associated synchronous noise go away, but we can prevent
> them from leaking out the cabinet. In a general engineering practice, the
> mechanical designer and the electrical designer will work together to
> achieve the optimum EMI design to assure the worst EMI radiation caused by
> clocks and their synchronous data are well shielded to comply to the EMI
> emission limit set by agencies. Any equipment can pass those worst emission
> test will automatically pass the relatively non-existing IDLE emission test.
>
> For example, the EMI test report from a Gibe equipment has the highest EMI
> emission level of 20 dBuv/m caused by clock related signals shown as the
> harmonics of a clock frequency. The rest of emission levels are well bellow
> 10 dBuv/m level. The upper limit of emission level of FCC Class B is 40
> dBuv/m, which still allows 20 dBuv/m margin for the equipment. As long as
> the good, commonly practiced EMI design is implemented, EMI is not the major
> problem.
>
> I believe, the codes, 8B/10B, scramble, PAM.... etc by itself will not cause
> EMI problem. However, the clocks and associated synchronous signals will
> cause EMI problem, if EMI design is not correctly implemented.
>
> Regards,
>
> Edward S. Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> Tel: (610)292-2870
> Fax: (610)292-2872
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Joel Goergen
> Sent: Wednesday, March 29, 2000 11:57 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: New thread on EMI
>
> Ed,
>
> I was hoping you would expand on this more, but these other data patterns
> you
> refer to, what percentage would you see them as taking in 'everyday' network
> traffic? Relative to idle, are they such a small percentage, or does data
> you
> have collected over the years indicate this to be a viable concern.
>
> I have not as yet analyzed any network data to determine if there is
> anything
> deterministic about the day to day spectral content, other then idle. I
> suspect
> not, but until one actually looks at it, it is difficult to answer with
> certainty. I would really like to here more thoughts here.
>
> Take care
> Joel Goergen
>
> > There are many other data patterns with much stronger signals to cause
> more
> > EMI headache for a system, than the occasional IDLE signals. Therefore,
> > IDLE should not become a problem, if the system is well designed to pass
> EMI
> > test for all repetitive strong signals; for example, clocks and their
> > synchronous data.
> >
> > AS a result, if we only take care of IDLE by scrambling, the system still
> > need a good EMI design to prevent those, strong, repetitive clock and
> > synchronous data signals to cause EMI problem. It implies scrambling the
> > IDLE is unnecessary.
> >
> > Regards,
> >
> > Edward S. Chang
begin:vcard
n:Truman;Tom
tel;pager:877-705-2496
tel;fax:732-949-9118
tel;work:732-949-8809
x-mozilla-html:FALSE
org:Bell Laboratories;High Speed Communications VLSI Research
version:2.1
email;internet:truman@xxxxxxxxxx
title:Member of Technical Staff
adr;quoted-printable:;;4E-511A=0D=0A101 Crawfords Corner Road;Holmdel;NJ;07733;USA
x-mozilla-cpt:;21872
fn:Tom Truman
end:vcard