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

Re: New thread on EMI




Hi Tom:

All clocks can cause  EMI problem in different degree, because they are 
repetitive, high frequency (not only its clock frequency also its sharp rise 
time), and the synchronous data of associated chip sets (increase the 
strength).  

The clocks and data are always connected to more than one chips to make them 
distributed on a PC board.  The board layout will dictate their routes.  You 
can optimize the design to minimize EMI emission to certain extent, but you 
cannot be sure quantitatively.

Comparing to the amplitude of the EMI emissions generated by multiple clocks 
and data lines, the EMI emission from an IDLE signal is small.  If an EMI 
design can satisfy clocks/datas, then IDLE is not a problem.

You should take a look at the actual EMI test report to appreciate it.
    
Regards,

Ed Chang



   





<< 
 The encoder/decoders do have clocks, but they would be much lower frequency 
than
 the chip-to-chip serial interconnect baud rate(assume >= 2.5 Gbaud, for
 illustration). 
 The serializer/deserializers would take a lower frequency external reference 
and 
 internally bring it up to the required high frequency rate. So, at the board
 level,
 the only high frequency signal (relevant to this discussion) are the
 chip-to-chip
 serial interconnect. 
 
 Or are you planning on distributing multi-GHz clocks at the board level in 
your
 designs?!
 
 Tom Truman
 Lucent Technologies / Bell Labs
 
 Edward Chang wrote:
 > 
 > Hi Tom:
 > 
 > When we discuss EMI issue here, we are dealing with the whole circuit board
 > which has MAC, PHY and MDI.  While coded data dose not have a clock, the
 > encoder or decoder have clocks.  Coder and decoder are part of the whole 
EMI
 > issue we are discussing, but not just the coded data.
 > 
 > Regards,
 > 
 > Edward S. Chang
 > NetWorth Technologies, Inc.
 > EChang@xxxxxxxxxxxxxxxx
 > Tel: (610)292-2870
 > Fax: (610)292-2872
 > 
 > -----Original Message-----
 > From: Tom Truman [mailto:truman@xxxxxxxxxxxxxxxxxxx]
 > Sent: Thursday, March 30, 2000 10:59 AM
 > To: Edward Chang
 > Cc: goergen@xxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
 > Subject: 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
 
 
 ----------------------- Headers --------------------------------
 Return-Path: <owner-stds-802-3-hssg@xxxxxxxx>
 Received: from  rly-yd01.mx.aol.com (rly-yd01.mail.aol.com [172.18.150.1]) 
by air-yd03.mail.aol.com (v70.20) with ESMTP; Thu, 30 Mar 2000 20:35:27 -0500
 Received: from  ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by 
rly-yd01.mx.aol.com (v70.21) with ESMTP; Thu, 30 Mar 2000 20:34:55 -0500
 Received:  by ruebert.ieee.org (8.9.3/8.9.3)   id UAA02668; Thu, 30 Mar 2000 
20:22:13 -0500 (EST)
 Message-ID: <38E3FC09.FDE786E1@xxxxxxxxxxxxxxxxxxx>
 Date: Thu, 30 Mar 2000 20:14:49 -0500
 From: Tom Truman <truman@xxxxxxxxxxxxxxxxxxx>
 Reply-To: truman@xxxxxxxxxxxxxxxxxxx
 Organization: Bell Labs
 X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (WinNT; U)
 X-Accept-Language: en
 MIME-Version: 1.0
 To: Edward Chang <edward.chang@xxxxxxxxxxxxxxxx>
 CC: goergen@xxxxxxxxxx, stds-802-3-hssg@xxxxxxxx
 Subject: Re: New thread on EMI
 References: <NDBBLFICGKDCKJBHKIAEKELLCBAA.edward.chang@xxxxxxxxxxxxxxxx>
 Content-Type: multipart/mixed;
  boundary="------------3B83C2F77706A1FFD36C5A39"
 Sender: owner-stds-802-3-hssg@xxxxxxxx
 Precedence: bulk
 X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
 X-Listname: stds-802-3-hssg
 X-Info: [Un]Subscribe requests to  majordomo@xxxxxxxxxxxxxxxxxx
 X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
 
  >>