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
>>