Re: 64/66 control code mapping
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