Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 64/66 control code mapping


I would like to second a statement that I believe you implicitly made
below.  8b/10b has been around for quite some time, and there is a
significant body of knowledge cataloged on its characteristics.  It seems
that the best approach is to leverage this knowledge base unless the code
is proven to be deficient.


At 04:17 PM 3/15/00 -0800, Rich Taborek wrote:
>Sorry for the late response to your note. You're absolutely right about my
>"laying it on a little thick" about how good 8B/10B is. However, I've worked
>with this code for well over 15 years now (yes, this predates the patent) and
>have seen other coding schemes try to displace it for specific
applications and
>fail miserably. In this note I'll provide a little bit of history as well as
>argument as to why 8B/10B is the best code to use for XAUI.
>Way back in the 70's and 80's I was working for IBM and Amdahl and had the 
>pleasure of growing up with early high speed serial link architectures in the
>200 Mbps range. Please note that I said 80's and that I was working on serial
>link PRODUCTS, not theses, that operated at only ~1/6 the line rate of GbE 
>and ~1/16 the line rate of the proposed 8B/10B encoded XAUI serial line
rate. I
>think that's pretty impressive in terms of what 8B/10B coding enabled early 
>technology to do!
>Back in the very early 90's, and I believe the actual year was 1991 or so, 
>Channel was in its infancy. The base proposal for the Fibre Channel PHY layer
>came from a serial link protocol employed by IBM on their AS/400 and RS/6000
>systems. Once that was accepted as the base proposal, coding wars ensued. 
>One of
>the candidate codes was... you guessed it... 8B/10B. My recollection of the 
>was that the FC committee took approximately a year to evaluate
approximately a
>dozen codes for use in Fibre Channel. During that year, evaluation
criteria was
>developed to rate all candidate codes for FC applications. When all was said 
>done, 8B/10B ranked so far above and beyond all other candidate codes that the
>vote for 8B/10B was unanimous, including supporting votes from proposers
of ALL
>other candidate codes. I was in awe of the job that Mr. Al Widmer did to win 
>support of the FC committee for 8B/10B back then, and I still am now. 
>8B/10B is currently far and away the dominant high-speed chip-to-chip, 
>and copper/fiber-based serial link code employed in the data communications
>industry today. I believe it has plenty of steam and credibility to
provide the
>optimum solution for 10 Gbps chip-to-chip, backplane and even some
>copper/fiber-based serial link applications and that's only pushing it 16X
>the line rate used in the early 80's. So much for history. Here's why:
>Argument for 8B/10B on XAUI:
>In the previous notes on this thread I made the statement that special codes
>"simplify synchronization, delineation, error checking, parallel lane deskew,
>jitter control, clock tolerance compensation, etc." and you questioned the
>relevance. This section of the note explains the relevance.
>XAUI is proposed as an XGMII extender. As such, it's primary application 
>will be
>to provide implementation flexibility in the form of an extended interconnect
>between Ethernet PHY sublayers. In general, only one such extension is 
>employed in a given implementation. Some of the goals for the XAUI interface 
>no significant order) are as follows:
>- Low pin count
>- Low power
>- Jitter containment/control
>- Clock tolerance compensation
>- Fast reset/sync
>- Use of common PCB materials
>- Low cost
>- Error containment/control
>- Fast packet delineation
>- Relatively long distance
>- Ability to handle local and medium skew
>- Protocol independence
>- PMD independence
>- Good signal integrity
>- Low EMI
>- Ability to transport LAN and WAN data
>- Simplicity
>- Familiarity
>- Scalability
>- Low/no intellectual property protection 
>The proposed XGMII is a 37-bit clocked interface in each direction and is
>take a gamble here) widely accepted within 802.3ae. The XGMII fails 
>miserably in
>meeting some of the above goals including low pin count, skew handling, low
>power, jitter containment and long distance. Extending the XGMII by using a
>single self-timed serial link in each direction does not address the goals of
>jitter containment, signal integrity, low EMI and any appreciable distance.
>Therefore, the universal answer for XAUI (at 10 Gbps) is a parallel
>of (4) serial lanes. This is also widely accepted in 802.3ae as evidenced by 
>Albuquerque 8B/10B-based XAUI/XGXS, SUPI, SLP and 64B/66B proposals. However,
>there is one key distinction between 8B/10B and SUPI, SLP and 64B/66B. That is
>that 8B/10B is a short block code and all competing codes (for XAUI) are
>relatively long block codes. It is this characteristic that helps 8B/10B meet
>the above goals in a much more optimized manner than its competitors.
>Short vs. Long block codes and Striping:
>Long block codes including SLP, SUPI and 64B/66B are designed for use over
>single serial lanes. The "striping" of these codes over a single serial
lane is
>straightforward and coding efficiency becomes important as high data transport
>rates are required. This happens to be especially true at the intersect of 10
>GbE and OC-192 insofar as reuse of existing 10 Gbps opto-electronics and 
>components is concerned. However, XAUI is a 4-lane interface requiring the
>code to be striped among the 4 lanes. It should now be evident from the number
>of 802.3ae supporters for 8B/10B column-striping over word-striping (I count
>only 1 for word-striping) that column-striping is preferred for XAUI. For many
>of the very same reasons given for column-striping vs. word-striping, an
>column-striped approach is far superior to any possible mapping of long-block
>codes for XAUI.
>Take SLP as an example. SLP mapped to XAUI would logically be mapped in one of
>two ways. Theoretically, many other striping granularities, such as
>word-striping, are possible but I fail to see any benefits in doing so: 
>1) Stripe SLP frames one-by-one each of 4 lanes;
>2) Stripe SLP frames byte-by-byte on 4 lanes.
>Obviously method (1) striping whole SLP frames on each lane does not lend 
>to chip-to-chip interconnect or backplane applications since the buffer sizes
>and control logic required to buffer variable sized SLP frames encapsulating
>Ethernet packets would be unwieldy. Method (2) is fatally flawed for the
>following set of reasons:
>a) Individual Lane as well as 4-lane Link synchronization is not achievable 
>the present SLP proposal since no deskew methodology has been proposed. Note
>that SLP non-scrambled /A/K/R/ sequences as used by 8B/10B would create an EMI
>exposure similar to that of 8B/10B and the the insertion/removal of /R/s would
>invalidate the SLP T-flag (EOP indication).
>b) The SLP proposal does not support clock tolerance compensation as does 
>by the insertion/removal of /R/ columns since doing so would compromise
the SLP
>T-flag. Such a compromise increase significantly the probability of false
>as well as undetected packet error not to mention the complexity of the
>synchronization logic.
>c) Synchronization is slow and complex is based on the detection of multiple
>possible control patterns as is the case of supporting other 10 GbE features
>such as Busy Idle, or any similar special control codes which have been 
>for supporting all-optical switches ((NTT Albuquerque proposal) or Fibre
>Channel/InfiniBand specific control codes. 
>d) Single lane synchronization, as simple as 8B/10B comma detection, is not
>possible since SLP requires the detection of multiple long patterns across all
>lanes to acquire link sync. Link and system problem determination as well as
>scalability to higher speeds are all significantly compromised.
>e) SLP frames provide no error detection or containment capabilities for
>transported data thereby increasing the undetected error rate of the link.  
>To a lesser extent (not much less) the same general argument above applies to
>the use of SUPI or 64B/66B as a XAUI encoding.
>In a nutshell, its the easily discernible 8B/10B control codes, discernible 
>on a
>lane-by-lane basis, that enable parallel lane deskew of multiple serial lanes,
>clock tolerance compensation, jitter control, etc. 
>I invite supporters of long block code alternatives to 8B/10B coding for 
>XAUI to
>enter this debate to see if I'm overlooking some major advantage of the former
>codes. I'll address EMI concerns of 8B/10B in a separate thread to help
keep us
>on track.
>Best Regards,
>"Benjamin J. Brown" wrote:
>> Rich
>> Rich Taborek wrote:
>> >
>> > In the case that the PCS is 64B/66B in support of a Serial PHY type, I 
>see no
>> > requirement for 8B/10B encoding/decoding to be performed. The fact that 
>both the
>> > XGMII and 64B/66B support special codes to simplify synchronization,
>> > delineation, error checking, parallel lane deskew, jitter control, clock
>> > tolerance compensation, etc. and that these codes are similar to those 
>used by
>> > 8B/10B are a credit to the elegant and timeless nature of the 8B/10B
>> > transmission code developed by Widmer, et. al.
>> >
>> It sounds like you're laying it on a little thick with
>> "the elegant and timeless nature of the 8b10b"! Though I
>> agree that this encoding has enjoyed much success, and
>> deservedly so, I don't believe this accounts for any need
>> of "parallel lane deskew, jitter control, clock tolerance
>> compensation, etc" codes in 64b/66b. This encoding has no
>> inherent parallel features which need to be deskewed and
>> I can't see how any special codes can be used for jitter
>> control or clock tolerance.
>> Please enlighten the less fortunate ;^)
>> Ben
>> --
>> -----------------------------------------
>> Benjamin Brown
>> Router Products Division
>> Nortel Networks
>> 1 Bedford Farms,
>> Kilton Road
>> Bedford, NH 03110
>> 603-629-3027 - Work
>> 603-629-3070 - Fax
>> 603-798-4115 - Home
>> bebrown@xxxxxxxxxxxxxxxxxx
>> -----------------------------------------
>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