RE: 8b/10b and EMI Levels
While back I send relative intensity for different 8B/10B patterns, which bounced
from the reflector. The are uploaded to the reflector if you like to see them.
I am sorry but this message, due to the size of the attachments exceeds the
reflector size limit and has been bounced to me as the list owner. I have
extracted the files and have placed them on the web site. If you could please
now re-send this e-mail, referring to the URLs supplied below rather than
attaching the files, you should be okay now.
------------- Begin Forwarded Message -------------
Date: Thu, 16 Mar 2000 12:16:40 -0800 (PST)
From: ghiasi <ghiasi@xxxxxxxxxxxxxxxxxxx>
Subject: RE: 8b/10b and EMI Levels
To: truman@xxxxxxxxxx, richard_dugan@xxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx, ghiasi@xxxxxxxxxxxxxxxxxxx
At same power level the output spectrum of following data patterns were:
K28.5 ~ -6.4 dBm
k28.3 ~ -2.5 dBm
SKP ~ -7 dBm
FC CRPAT ~ -14.5 dBm
FC CJTPAD ~ -2.56 dBM
10K random 8B/10B ~ -18.4 dBm
FC Idle ~ -8.24 dBm
FC SOF ~ -8.3 dBm
FC EOF ~ -8.4 dBm.
As illustrated here the difference between random 8B/10B data vs repeated data
is about 16 dB! Some believe if you scramble your idle then it is sufficient to
reduce the EMI. If you scramble your data and idle then you would need a
different SerDes, as the existing SerDes will not properly get aligned.
> From: "DUGAN,RICHARD (HP-SanJose,ex1)" <richard_dugan@xxxxxxxxxxx>
> To: "'Tom Truman'" <truman@xxxxxxxxxx>
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: 8b/10b and EMI
> Date: Wed, 15 Mar 2000 12:49:42 -0700
> MIME-Version: 1.0
> 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
> Actually the P1394B implementation scrambled the data BEFORE it went
> throught he 8b/10b block encoding. That is, all the "benefits" of 8b/10b
> block coding were preserved (low run length, error monitoring, etc.) The
> idea was simply to randomize the 8b/10b characters so neither IDLES nor data
> would send repetitive patterns.
> - Richard
> -----Original Message-----
> From: Tom Truman [mailto:truman@xxxxxxxxxx]
> Sent: Wednesday, March 15, 2000 8:13 AM
> To: Ed Grivna
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: 8b/10b and EMI
> 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
> 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
> > > or in Joel Goergen's presentation). My impression is that component
> > > 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
> > > these issues, as ultimately the goal is to get product out the door that
> > > satisfies FCC/ETSI regulations.
> > >
> > >
> > > Tom
------------- End Forwarded Message -------------