Re: 64/66 control code mapping
One of the strongly supported architectures for a 10 GbE link employing the
XGMII, XAUI/XGXS using 8B/10B code and a 64B/66B-based Serial PCS depend on
special codes delineating packets to enable a myriad of link implementations.
What I was pointing out in my previous response is that an XGMII extender,
although optional like the XGMII, must be supported by the architecture.
Proposed 64B/66B special code encodings provide the required support for the
only XAUI/XGXS proposal which can be proven to meet all the desired goals of an
Stating that XAUI/XGXS control codes need not be supported by a PCS, eliminates
the option of supporting XAUI/XGXS. This means that XGMII extension would not be
supported by the 10 GbE standard. This would in turn significantly limit the
implementation flexibility of 10 GbE products. I hope that my previous response
has convinced you that a "serial stream encoder" like 64B/66B or SLP or SUPI can
not work as a XGMII extender.
The proper technical solution is already proposed in Mr. Rick Walker's 64B/66B
Albuquerque presentation. In addition to supporting the optional XAUI/XGXS XGMII
extender architecture, 64B/66B provides the following additional benefits:
1) Supports Mr. Howard Frazier's UniPHY proposal providing direct LAN PHY
mapping to SONET;
2) Supports additional control codes to provide full support of non 10 GbE
protocols including 10 GFC and InfiniBand;
3) Supports extensions to provide direct mapping of a LAN PHY to Optical
Cross-Connects ala proposals such as those introduced by Mr. Osamu Ishida of NTT
4) Combines (1) and (2) or (3) to provide direct mapping of non 10 GbE protocols
including 10 GFC and InfiniBand directly to SONET or Optical Cross-Connects in
the same manner as for 10 GbE.
I know that many 802.3 give a hoot about 10 GFC or InfiniBand, but there are
potential huge volumes behind each of these which can only help reduce 10 GbE
costs to the end user;
"Benjamin J. Brown" wrote:
> 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.
> 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
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