Re: 64/66 control code mapping
Hi Rich,
here are answers to your questions:
>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.
I don't know where "SLP frames" came from? SLP is a byte by byte mapping of
packets (for instance ethernet packets). We never suggested to send frames on
each lane. For a XAUI type interface the striping could be anything, byte or
word striping or other schemes.
>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
Yes, but no-one ever proposed this...
>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).
Regardless of whether a packet delineation scheme is scrambled or un-scrambled,
bytes sent on four lanes can be scrambled, using EMI-optimized scrambling. In
their SUPI proposal, Nortel presented an elegant way to do deskewing in a
"protocol
independent" fashion. For instance by removing one byte of idle per IPG, one
can insert un-scrambled columns of control characters such as:
A K R
A K R
A K R
A K R
(to be consistent with your byte striped HARI proposal). This requires an
insert/delete FIFO. A, K and R are bytes instead of 10b words. One can remove
a whole column of Rs without affecting the T-flag. Please note the line rate on
each lane can be exactly 2.500 Gb/s. No rate conversion circuitry is necessary.
>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.
T-flag is not affected. Probability of false match is if I remember well, on the
order of once every 2000 billion years for perfect match, and once every ~14
million years for match with 3 bit error tolerance.
>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.
Synchronization is not slow and complex. I also disagree with your statement
that SLP is specific to ethernet, and can not support a large set of
control codes. We showed that with a 4b Hamming distance one can support up
to 16 control characters. By using a control character such as "O", one can
create ordered set control for fibre channel (ODDDODDD...). It can support
other control words too (up to 16).
>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.
The scheme described above is scalable to other speeds.
>e) SLP frames provide no error detection or containment capabilities for
>transported data thereby increasing the undetected error rate of the link.
64b/66b does not provide data error detection capability. How come ethernet
works well with 64b/66b that does not support error detection?
>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.
SUPI was proposed by Nortel more as a PMD interface, not for XAUI, but I
don't see why it couldn't work for XAUI.
on the other hand:
64b/66b does not work for XAUI. The encoding does not allow mapping things like
------------------------------
D D D T I I I S, which you can observe on a lane of HARI. Therefore 64b/66b
is not a candidate. And I don't recall Rick Walker or Rich Dungan ever
saying that it could be used in HARI.
***
Hope this clarifies a bit
Regards,
Kamran
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