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

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
> > 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
org:Bell Laboratories;High Speed Communications VLSI Research
title:Member of Technical Staff
adr;quoted-printable:;;4E-511A=0D=0A101 Crawfords Corner Road;Holmdel;NJ;07733;USA
fn:Tom Truman