Re: 8b/10b and EMI
Hi Rick,
thanks for your response below, and I agree with you guys that if
the decision is to stick to 8b/10b and use scrambling on the top of it for
improving EMI, then scrambling should be prior to the block code. One
problem right now, is that this is not a proposal. Is it?
Kamran
Rick Walker wrote:
>
> 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