Re: 64/66 control code mapping
Rich-
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.
JR
At 04:17 PM 3/15/00 -0800, Rich Taborek wrote:
>
>Ben,
>
>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.
>
>History:
>
>Way back in the 70's and 80's I was working for IBM and Amdahl and had the
>great
>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
>links
>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
>80's
>technology to do!
>
>Back in the very early 90's, and I believe the actual year was 1991 or so,
>Fibre
>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
>time
>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
>and
>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
>the
>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,
>backplane
>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
over
>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
>typically
>employed in a given implementation. Some of the goals for the XAUI interface
>(in
>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
(I'll
>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
arrangement
>of (4) serial lanes. This is also widely accepted in 802.3ae as evidenced by
>the
>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
>support
>components is concerned. However, XAUI is a 4-lane interface requiring the
XAUI
>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
8B/10B
>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
>itself
>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
>with
>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
>8B/10B
>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
match
>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
>proposed
>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,
>Rich
>
>--
>
>"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 http://www.nSerial.com
>