RE: 8b/10b and EMI packaging
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
At 01:40 PM 3/15/2000 -0500, you wrote:
>
>Tom and ALL:
>
>Usually the board is inside a cabinet. The EMI test is based on a system,
>but not a component or a board. The enclosure is usually well designed to
>shield all radiations both in and out. The only possible leak is the copper
>cables. In an optical system, a cable is not a concern at all.
>
>Although, if the transceivers are not well designed for EMI concerns, and an
>excessive radiation parts may cause some headache; however, in general, the
>8B/10B code has been used for many years, and I have not heard anyone had
>EMI problem. I never had experienced any EMI problem at all in my products.
>
>The key is to design a enclosure being well shielded from radiation.
>
>
>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 Tom Truman
>Sent: Wednesday, March 15, 2000 11:13 AM
>To: Ed Grivna
>Cc: stds-802-3-hssg@xxxxxxxx
>Subject: Re: 8b/10b and EMI
>
>
>Ed,
>
>Thanks for the response.
>
>If 8b/10b were to be scrambled, then it would appear
>to me that all it is providing at the XAUI interface is packet delineation
>and some error monitoring capability. I imagine that each lane would need
>a separate scrambler/descrambler, initialized to different states so that
>the transitions across the lanes are uncorrelated. Synchronizing these
>scramblers,
>and deskewing the lanes would require some thought -- it isn't difficult,
>but it isn't as straightforward as the "alignment column" proposed for HARI.
>
>At that point, the 25% overhead of the 8b/10b scheme
>seems to be a staggering price to pay for delineation and
>error monitoring -- why not start with scrambling, at a lower baud rate, and
>make the overall design problems simpler?
>
>Best regards,
>Tom Truman
>Lucent Technologies
>
>
>
>Ed Grivna wrote:
>>
>> Hi Tom,
>>
>> a good source of data onthis can be found in the IEEE 1394b development
>> archives. Since 1394b maskes use of 8B/10B encoding, and they spend
>> a lot of effort on EMI reduction, there should be a significant number
>> of papers/presentations available on the subject.
>>
>> As a background on what I remember, it is definately possible to
>> create "hot spots" in the radiated emission spectrum if you keep
>> repeating a short sequence of characters. This occurs in Fibre Channel
>> systems with their 4-character Idle sequence. To get around this,
>> 1394b added a level of scrambling to both the source data cahracters
>> AND to the command characters used, prior to sending them through the
>> 8B/10B encoder. By doing this they were able to achieve some dramatic
>> (sorry, I can't remember the number of dB) reduction in radiated
>> emissions.
>>
>> The 8B/10B code, when sending random data, has a fairly wide emissions
>> spectrum (which is what you want), but if you sit on the same
>> character or small group of characters, you can see the discrete
>> spectral peaks quite clearly.
>>
>> Regards,
>>
>> Ed Grivna
>> Cypress Semiconductor
>>
>> >
>> > I would like to raise the issue of EM emissions with 8b/10b
>> > vs. scrambling (spectrum comparisions can be found in the SLP
>presentation
>> > or in Joel Goergen's presentation). My impression is that component
>vendors
>> > are leaving this problem for the system integrators to solve.
>> >
>> > Has anyone looked into the issue of EMI/EMC within the context of system
>> > cost and time-to-market?
>> >
>> > While system integration and implementation are
>> > beyond the scope of the standard, it would be grossly negligent to
>ignore
>> > these issues, as ultimately the goal is to get product out the door that
>> > satisfies FCC/ETSI regulations.
>> >
>> >
>> > Tom
>