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

RE: 8b/10b and EMI packaging




Hi Dan:

It is possible that the repetitive IDLE pattern may cause EMI problem, if it
was left without any enclosure.

Inside a cabinet, there are many other repetitive signals; namely, serial
clock, transmit byte clock, receive byte clock, other logic clocks, and I/O
interface clocks...etc.  They are synchronous to their own chip sets.  In
addition to their own repetitive fixed frequency spectrum, they are aided by
their own synchronous chip sets to further enhance the strength of its EMI
radiation.  Yet, the enclosure is designed to shield all of these strong
repetitive signals from radiating to outside of an enclosure.

The occasional repetitive IDLE signal is much in-frequent, and much weaker
than those synchronous clocks and their associated signals.  Therefore, an
enclosure can stop the repetitive IDLE signals from leaking out.


Regards,

Edward S. Chang
NetWorth Technologies, Inc.
EChang@NetWorthtech.com
Tel: (610)292-2870
Fax: (610)292-2872



-----Original Message-----
From: owner-stds-802-3-hssg@ieee.org
[mailto:owner-stds-802-3-hssg@ieee.org]On Behalf Of DOVE,DANIEL J
(HP-Roseville,ex1)
Sent: Thursday, March 16, 2000 8:00 PM
To: stds-802-3-hssg@ieee.org
Subject: RE: 8b/10b and EMI packaging



Hi Ed,

I agree that most codes, when random data is applied to them,
will generate a random looking EMI profile. However, EMI tests
require that you configure your system to a real-world
arrangement that is likely to exist for your customer.

In the real world, there are many times when a link will be idle.

If the IDLE sequence that is continously being run just happens to
have a recurrent pattern with a high repetition rate, the EMI that
comes out may be as much as 20dB higher than the random data patterns.

So you have to consider the EMI implications of an IDLE link just as
much as you do a link driven with random data. The FCC/CISPR do not
require us to generate worst-case data patterns for testing, but you
don't want your worst-case (or near worst-case) to be the IDLE
condition because that will be required.

Regards,

Dan

>  -----Original Message-----
>  From: Edward Chang [mailto:edward.chang@NetWorthTech.com]
>  Sent: Thursday, March 16, 2000 8:40 AM
>  To: goergen@lucent.com; stds-802-3-hssg@ieee.org
>  Subject: RE: 8b/10b and EMI packaging
>
>
>
>  JoeL and all:
>
>  The coding and EMI is related to certain extent, but EMI is
>  not the main
>  criteria for code design.  The main objective of a code
>  design is a maximum
>  data rate, and a reliable data recovery, which deal with
>  issues of BER,
>  base-line wander, clock recovery, minimum transitions per a
>  bit time, and
>  perhaps some other protocol issues.
>
>  After a code meets all these requirements, the frequency
>  spectrum of the
>  data stream is usually pretty much randomly mixed without a
>  predominant
>  peaking frequency to cause an specific EMI problem.  Very
>  seldom, if any, a
>  designer has go back to tweak the code to avoid a specific
>  EMI problem,
>  except the naked twisted pair.  The unshielded twisted pair,
>  EMI issue is a
>  fundamental radiation issue, and it is unfair to blame the
>  coding technique.
>
>  I believe we all agree that a coding technique should not add any
>  unnecessary EMI headache.
>
>
>  Regards,
>
>  Edward S. Chang
>  NetWorth Technologies, Inc.
>  EChang@NetWorthtech.com
>  Tel: (610)292-2870
>  Fax: (610)292-2872
>
>
>
>
>
>
>
>
>
>
>  -----Original Message-----
>  From: owner-stds-802-3-hssg@ieee.org
>  [mailto:owner-stds-802-3-hssg@ieee.org]On Behalf Of Joel Goergen
>  Sent: Thursday, March 16, 2000 7:36 AM
>  To: stds-802-3-hssg@ieee.org
>  Subject: Re: 8b/10b and EMI packaging
>
>
>
>  Hello,
>
>  But what you are all missing in your comments is what Tom
>  Truman pointed out
>  in
>  Albuquerque - that the choice of coding is an NRE within an
>  asic, but the
>  EMI
>  performance, either designed in or designed after the fact,
>  is NOT an NRE
>  but in
>  fact, a re-occuring charge each time a product is sold.  At
>  what time period
>  within a project we apply EMI design methods, the size of
>  the project, and
>  who
>  implements those methods, directly relates to the re-occuring costs.
>
>  At the last few meetings, everyone had cost as something
>  they want to keep
>  low,
>  and about every fourth person presenting indicated 'we all
>  want to make
>  money'.
>  So, wether we have EMI problems or not, anti-EMI costs money
>  - period.  So,
>  if
>  we can stick some of it back into NRE and out of product
>  cost, we all make
>  more
>  money.
>
>  The last point Dan Dove already made and that was based on Jonathan's
>  remarks:
>  "This might have been said about 10 or 100 or 1000. We will
>  see. Rather
>  than choose a "spikey" code and roll the dice, I would recommend
>  using careful consideration for the code.. then roll the dice. :)"
>
>  Just my thoughts
>  Joel
>  ---------------
>  Edward Chang wrote:
>
>  > Wayne:
>  >
>  > You are right, no question about it.  As long as it is
>  cost-effective, all
>  > parts including component package, board layout, circuit
>  design, cable
>  > dressing ... should use the good common practice to avoid
>  the unnecessary
>  > EMI headache.
>  >
>  > Regards,
>  >
>  > Edward S. Chang
>  >
>
>  > Comment from a reflector-lurker:
>  >
>  > Regarding EMI design, I should point out that the most
>  > cost-effective system designs take EMI characteristics
>  > into the basic board designs to such a degree that EMI
>  > is reduced at the source as much as possible.  This
>  > not only improves the stability and manufacture of the
>  > designs, but also allows for cheaper packaging materials
>  > for the enclosures (which can really affect today's
>  > competitive edge on appearances and cost - use of
>  > plastics and the like).
>  >
>  > Just my two-cents worth!
>  >
>  > Best to you,
>  > Wayne Belshaw
>  > Amdahl Corporation
>  >
>
>  --
>  Joel Goergen
>  Member of Technical Staff
>  High Speed Communications VLSI Research
>  Bell Laboratories, Lucent Technologies
>  10250 Valley View, Suite 113
>  Eden Prairie, MN, 55344
>
>  Email:  goergen@lucent.com
>  Direct: (612) 996-6932
>  Cell:  (612) 670-5930
>  Fax:    (612) 996-6995
>
>