Re: 64/66 control code mapping
Joel,
I realized yesterday while analyzing SLP as a XAUI code that your Albuquerque
presentation of PCB trace analysis of 8B/10B @ 3.125 Gbaud vs. scrambles @ 2.5
Gbaud shows better eyes for 8B/10B than scrambling for 5 out of 6 cases. In
addition, I realized that any EMI comparison between the two methodologies must
consider the EMI of an Idle pattern rather than a scrambled data stream. The
referenced presentation can be found at
http://grouper.ieee.org/groups/802/3/ae/public/mar00/goergen_1_0300.pdf
Ignoring all slides at >3.125 Gbaud since they are not relevant to XAUI traces,
the 8B/10B eye is superior to the slower scrambled eye in:
1) Slides 9,10,33: Test Setup AC-coupled
2) Slides 14,15,33: Test Setup DC-coupled
3) Slides 19,20,33: AC-coupled with 5.5" differential pair
4) Slides 24,25,33: AC-coupled with 11" differential pair and two vias
5) Slides 28,29,33: DC-coupled with 5.5" differential pair
The only slides which show the scrambled eye to be superior is for the case of a
22" differential pair and 4 vias in slides 26,27,33. In these slides it appears
to me that the positioning of the vertical axis cursors used to indicate the
vertical eye opening is a bit ambiguous. There is clearly less ISI apparent in
the 8B/10B eye (slide 27) than in the scrambled eye (slide 26).
In a nutshell, the "eye" analysis seems to be either inconclusive or
questionable since 8B/10B seems to "fall off a cliff" with respect to scrambling
somewhere between 11"/2 vias and 22"/4 vias. Where is the cliff and what
accounts for it? This is why I'm having great difficulty with your suggestion to
"slow down XAUI a bit".
EMI and Coding
--------------
I know you mentioned EMI in your presentation. However, there is no data in the
presentation comparing the EMI of an 8B/10B-based XAUI and a scrambling-based
XAUI. I know that you asked me for 8B/10B patterns in Albuquerque and I gave you
the worst case Idle pattern. I'd like to document both 8B/10B and scrambling
worst case Idle patterns for XAUI for anyone interested in doing a fair
comparison.
First of all, as Mr. Dan Dove pointed out in an EMI related note to this
reflector yesterday, the worst case pattern happens during Idle. It is well
known that EMI testing of GbE and FC equipment takes place while the equipment
is generating an Idle test pattern for many logistical reasons.
Secondly, EMI improves upon Skip (/R/ column) insertion and removal since this
process breaks up the repeated nature of the Idle stream. Therefore, the worst
case pattern appears at the initial XAUI transmitter.
For an 8B/10B-based XAUI the Idle pattern is /A/K/R/. /A/'s are transmitted
every 16 code-groups, /K/R/ repeats in between /A/s. Two 8B/10B code-groups
encodings are used to represent each of the Idle characters. The Idle pattern
was specifically chosen to ensure the longest possible non repeating Idle bit
pattern. The repeating Idle pattern in code-group format is:
/+A/-K/+R/+K/-R/-K/+R/+K/-R/-K/+R/+K/-R/-K/+R/+K/-A/+K/-R/-K/+R/+K/-R/-K/+R/+K/-R/-K/+R/+K/-R/-K/
The bit stream corresponding to the above code-group pattern is as follows:
001111 0011 110000 0101 001111 0101 001111 1010 110000 1011 110000 0101 001111
0101 001111 1010 110000 1011 110000 0101 001111 0101 001111 1010 110000 1011
110000 0101 001111 0101 001111 1010 110000 1100 001111 1010 110000 1011 110000
0101 001111 0101 001111 1010 110000 1011 110000 0101 001111 0101 001111 1010
110000 1011 110000 0101 001111 0101 001111 1010 110000 1011 110000 0101
Scrambling implies some specific protocol to enable data transport,
synchronization, clock tolerance compensation, packet delineation, etc. There
are no such proposals currently on the table for XAUI so I have to refer to the
"sneak peeks" of a potential proposal such as the Mr. Kamran Azadet's SLP
proposal
(http://grouper.ieee.org/groups/802/3/ae/public/mar00/azadet_1_0300.pdf) and
subsequent reflector discussion regarding its potential applicability as a XAUI
protocol.
On slide 8 Mr. Azadet proposes a scrambling scheme where the control codes which
correspond to the IPG are not encoded.
Note that although not scrambling the control codes provides a benefit to
mapping to a parallel-serial interface such as XAUI in terms of facilitating
synchronization, the tradeoff is that the control codes are much worse in terms
of EMI. an SLP Idle pattern equivalent to 8B/10B's /A/K/R/ has been proposed on
this reflector. Note that the actual repeating pattern is much shorter then that
of 8B/10B which will probably result in much higher (power) discrete spectral
lines than that of the 8B/10B Idle pattern:
/A/K/R/K/R/K/R/K/R/K/R/K/R/K/R/K/A/
The bit stream corresponding to the above code-group pattern is as follows:
00010111 01001110 01110100 01001110 01110100 01001110 01110100 01001110 01110100
01001110 01110100 01001110 01110100 01001110 01110100 01001110
Note that the above bit pattern may not be optimal since I have simply picked
the first three control codes from slide 11 of Mr. Azadet's presentation to
represent SLP /A/K/R/.
Don Alderrou of an nSerial and I have also suggested a simple method to reduce
the repeated nature of Idle by randomly relocating /R/ columns within an Idle
stream. I'm wondering if it's possible for you to simulate the benefits of such
a simple trick to reduce the EMI of an 8B/10B Idle stream. If not, it's OK, I'm
just completing my action item to document the 8B/10B-based XAUI Idle pattern
which should be compared against an SLP-based XAUI Idle pattern in any future
analysis.
Based on the above two issues with scrambled codes vs. 8B/10B and other
comparisons of pure scrambling vs. 64B/66B, it is not apparant to me that there
is any benefit of scrambling vs. 64B/66B for XAUI. Now if you're saying that
BOTH scrambling at 2.5 Gbps and 8B/10B at 3.125 Gbps are equally bad over FR-4
and simply won't work, then we have a real problem. However, your "eyes" don't
reflect that this is the case at all.
Best Regards,
Rich
--
Joel Goergen wrote:
>
> Kamran /Rick/All
>
> I know I still have more lab verification, and I know 8B10B is well known/used,
> but we have got to do something to slow the XAUI/HARI portion down a hair.
>
> Aside from concerns we have all been addressing, there were two more brought to
> my attention yesterday in a customer meeting. The first is if we are worried
> about being like Infiniband, and I am not saying we should be and I am not saying
> we should not be, but 8B10B at 3.125 in a PC is 'nuts because most PCs barely
> pass emissions as it is'. The addition of the spectral content of 8B10B could be
> a disater for that interface. We should be careful, if that is one of our
> resaons, about trying to be similar to an interface that most likely will have to
> change.
>
> The second actually bothered me more because I never thought about it and have to
> do some more verification to determine validity, but the customer pointed out
> that only fr-4 was readily available in his country, where as some of the
> materials I have been using was very difficult for them to find. That being
> said, with respect to skin effect of the geometry and the erratic loss tangency
> of fr-4 ( the real part isn't pretty either ), the slower speed can make a
> difference.
>
> > If it appears that 8B/10B is no longer desirable due to EMI and skin-loss
> > limitations on the PCB, we will be quite happy to present our ideas w.r.t.
> > using 64b/66b on the 4 XAUI lanes.
> >
> > --
> > Rick Walker
>
> Joel Goergen
-------------------------------------------------------
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