Re: 8b/10b and EMI
Tom,
Joel's presentation slide 41 says it is using Data Pattern 1 megabit in length
using PRBS and that the 8B/10B Pattern is an encoded data pattern. This seems to
be in conflict with what I heard Joel say at the meeting, the very discrete
spectral lines shown in slide 43, and this note from you which says that the
8B/10B pattern is actually an 8B/10B Idle sequence. Please clarify since this
makes a HUGE difference and renders the presentation as irrelevant.
Please see my note to Joel sent to this reflector earlier today that analyzes
this issue in detail.
In a nutshell, a fair apples to apples EMI comparison should pit the exact
8B/10B Idle pattern proposed for XAUI @ 3.125 Gbaud vs. an SLP protocol based
Idle pattern @ 2.5 Gbaud. If it's not SLP then describe exactly what it is that
you're running over XAUI as a 4-lane protocol which meets all of the objectives
of a XAUI protocol as does 8B/10B.
Best Regards,
Rich
--
Tom Truman wrote:
>
> Ron,
>
> Look at Joel Goergen's presentation from the March 2000 meeting --
> he has spectral plots of 8b/10b Idle sequences compared to
> scrambled -- there is at least a 10dB reduction in power for the
> scrambled version.
>
> Tom Truman
> Bell Laboratories
>
> Ron Miller wrote:
> >
> > Hi Ed
> >
> > All those that I know in fibre channel using GBICs has had problems when
> > the idle signal is sent. I do not know yet whether 8B/10B is the culprit,
> > but
> > idle signal sure seems to have accentuated the problem compared to a random
> > data stream.
> >
> > Has anyone done a spectral analysis of 46b/66b vs 8b/10b with idle
> > characters continuous?
> >
> > Thanks
> >
> > ron miller
> >
> > Edward Chang wrote:
> >
> > > Tom, Rick and all:
> > >
> > > If the only reason to scramble the 8B/10B code is to minimize the
> > > probability of EMI emission caused by the occasional, repetitive IDLE
> > > signal, we may have to ask ourselves a question: have we done enough home
> > > work to prove it is required? Even a simple circuit, it is not free.
> > >
> > > So far, in the real industry-wide installations, no one has the 8B/10B IDLE
> > > EMI problem. Furthermore, no one has proved that 8B/10B IDLE signals will
> > > cause EMI problem for 10 GbE in an enclosed environment.
> > >
> > > 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 Rick Walker
> > > Sent: Thursday, March 16, 2000 11:03 PM
> > > To: stds-802-3-hssg@xxxxxxxx
> > > Subject: Re: 8b/10b and EMI
> > >
> > > Dear Tom,
> > >
> > > Tom Truman <truman@xxxxxxxxxx> writes:
> > > > 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.
> > >
> > > It's not as bad as you think.
> > >
> > > The scrambling is done *prior* to 8b/10b encoding, so that the full
> > > run-length and DC-balance properties are preserved.
> > >
> > > The scramblers would be randomized by the data itself, and no special
> > > effort would be required to de-correlate them.
> > >
> > > > 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?
> > >
> > > Because the data is scrambled *prior* to coding, the benefits of 8b/10b
> > > are not lost. The net result is that the spectral properties are improved
> > > at the cost of some added circuitry.
> > > --
> > > Rick Walker
> >
> > --
> > Ronald B. Miller _\\|//_ Signal Integrity Engineer
> > (408)487-8017 (' 0-0 ') fax(408)487-8017
> > ==========0000-(_)0000===========
> > Brocade Communications Systems, 1901 Guadalupe Parkway, San Jose, CA 95131
> > rmiller@xxxxxxxxxxx, rbmiller@xxxxxxxxxxxx
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com