Re: 64/66 control code mapping
Rich,
I was worried about you today. With all the reflector traffic
and no response from you, I was wondering if we had stumped
you. I see that I was mistaken and you chose this time to
prepare your response (as a thesis? ;^) Sorry, I wouldn't
kid you if I didn't think you would take it in the spirit
in which it is given.
Anyways, I applaud your sincerity to 8b10b. I probably don't
understand all the advantages this code has over the other
codes and I always am entertained and educated when you
provide a lesson such as this one. However, I want to
clarify a couple of the points I made in an earlier message
which you refer to here.
When I questioned the relevance of special codes that
"simplify synchronization, delineation, error checking,
parallel lane deskew, jitter control, clock tolerance
compensation, etc.", I actually only questioned the last
3. Also, I wasn't questioning these with respect to 8b10b
encoding. I was questioning them with respect to 64b/66b.
The proposal that Rick Walker made in Albuquerque describes
a 64b/66b PCS that requires all the control code-groups of
the 8b10b based XAUI. These codes may well be very necessary
when encoding a lane with 8b10b for all the reasons you
have provided. I'm not arguing that. I'm arguing that
for a serial stream encoder like 64b/66b, these types of
code groups are irrelevant. I was arguing that 64b/66b
only needed to use the XGMII control codes of SOP, EOP,
ERROR, IDLE and possibly BUSY IDLE (should that be the
chosen method of rate adaption).
I don't recall the author of this thought but someone made
a very good point of asking why XGMII even has control
codes and doesn't simply use the control bit to know when
you're between packets and when you're within a packet.
I presume the immediate answer would be, "how would you
know the difference between EOP & ERROR and IDLE & BUSY IDLE".
An additional bit in each direction would solve this problem
and hey, when you're at 37 pins in each direction, what's
one more?
I would love to hear more responses to these concerns and
arguements. Though the 8b10b thread is an interesting one,
it was not a thread I intended to initiate with my questions.
As for EMI, I would be well out of my league to enter into
that discussion except to ask a few very naive questions.
I'll leave that to the experts.
Ben
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@nortelnetworks.com
> > -----------------------------------------
>
> -------------------------------------------------------
> 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@nSerial.com
> Santa Clara, CA 95054 http://www.nSerial.com
--
-----------------------------------------
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@nortelnetworks.com
-----------------------------------------