Re: 64/66 control code mapping
Ben,
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
XGMII extender.
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
in Albuquerque;
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;
Best Regards,
Rich
--
"Benjamin J. Brown" wrote:
>
> 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
>
> --
> -----------------------------------------
> 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