Re: New thread on EMI
Ed,
I'm not sure why you're arguing so vehemently against improving the spectral
characteristics and resultant EMI of the 8B/10B Idle stream for 10 GbE. I find
your arguments to be tantamount to arguing that we shouldn't be concerned about
the number of vias present in multi-gigabit PCB traces or the size of front
panel openings in equipment housings for multi-gigabit transceivers.
EMI testing or not, it can be readily shown that the currently proposed 8B/10B
/A/K/R/ Idle pattern PSD has spectral lines 20 dB higher than that of random
8B/10B data. I pointed out that there are methods to reduce this penalty by 15
dB or more by simple changes to the Idle pattern. Don't worry, K28.5 will still
be there with approximately the same frequency.
Several individuals working on EMI enhancements to the the 8B/10B Idle proposed
for 10 GbE for 4-lane usage (e.g. WWDM, XAUI) have achieved consensus on an
/A/K/R/ based Idle which is essentially randomized while maintaining all
qualities of the periodic /A/K/R/ pattern. We are now preparing a detailed
presentation which should be available to this reflector by the end of next
week.
The scrambling I mentioned in no way scrambles the 8B/10B encoded characters.
Only the ordering of the characters is effectively scrambled.
Are you really against this direction? If so, why?
Best Regards,
Rich
--
Edward Chang wrote:
>
> Rich:
>
> The EMI discussion is focused on the idle emission level, and the question
> is "Do we need scrambling to reduce the idle emission level"?. The answer
> is no. IDLE will not cause EMI problem, if the system is correctly designed
> to meet ordinary EMI requirements.
>
> As for other reasons to scramble the IDLE is another issue.
>
> Nevertheless, most of the component people do not appreciate the convenient
> tool of using the repetitive IDLE (K28.5) waveform to characterize the whole
> system and link.
>
> >From EMI point of view, scrambling the XGXS, XAUI, XGXS by 64b/66b code on
> top of 8B/10B code is unnecessary -- no on has EMI test data to prove it.
>
> However, as long as XGXS, XAUI, XGXS is an optional block, equipment vendor
> will chose whatever the cost effective approach.
>
> Regards,
>
> Edward S. Chang
> NetWorth Technologies, Inc.
> EChang@xxxxxxxxxxxxxxxx
> Tel: (610)292-2870
> Fax: (610)292-2872
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Thursday, March 30, 2000 9:19 PM
> To: Edward Chang
> Subject: Re: New thread on EMI
>
> Ed,
>
> Please allow me to address one of the point in your last note. Hopefully I
> can treat this point independently.
>
> Several individuals have been working on a proposal to scramble the 8B/10B
> /A/K/R/ Idle stream proposed for both XAUI and WWDM. The scrambling involves
> code-group-level scrambling rather than bit-level scrambling and all
> benefits of 8B/10B encoding as well as the Idle protocol would be preserved.
> The resultant Idle spectrum would be equivalent to that of a typical data
> stream generated by random workloads. There should be more details to report
> to the reflector by tomorrow.
>
> Best Regards,
> Rich
>
> --
>
> Edward Chang wrote:
> >
> > Hi Dan:
> >
> > ...
> >
> > I am not in favor of scrambling the IDLE signal, because a scrambled IDLE
> > signal can not be used for debugging a system by studying the waveforms.
> >
> > After power-up, the IDLE signal is continuously sent out from a SERDES,
> and
> > through the transmitter, cable and receiver, the IDLE signal is returned
> to
> > the SERDES without any debugging software help. It is a very convenient,
> > powerful tool to debug a system in the field by comparing the waveforms of
> > the sent IDLE and the received IDLE. Anything scrambled is becoming
> fuzzy,
> > which can not be used for accurate waveform diagnosis.
> >
> > Furthermore, scrambling the IDLE is not free, it came with other concerns.
> >
> > Regards,
> >
> > Edward S. Chang
> > NetWorth Technologies, Inc.
> > EChang@xxxxxxxxxxxxxxxx
> > Tel: (610)292-2870
> > Fax: (610)292-2872
-------------------------------------------------------
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