Re: 64/66 control code mapping
Rich,
I get the feeling we're not even on the same page. I have no
problem with using 8b10b over XAUI. Some folks discussing the
EMI issue may have problems but I don't want to confuse these
issues at this point.
Again, other than EMI issues, I'm in favor of 8b10b over XAUI.
I'm also in favor of using XAUI as an XGMII extender. I agree
that it fits well into your list of requirements for such an
interface.
My concern is why we need to use XAUI specific control codes
over the serial data stream. Why can't the PCS side of the
XAUI replace the XAUI specific control codes with XGMII
specific control codes? This conversion has to be done from
XAUI to reconciliation sub-layer so the logic must be
developed anyways. It makes the 64b/66b encoding much simpler.
Thanks,
Ben
Rich Taborek wrote:
>
> 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
--
-----------------------------------------
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
-----------------------------------------