Re: XAUI and 64b/66b
Walt,
As I understand it, no decisions have been made with respect to interfaces or
coding for 10 GbE as of yet. We have nothing but proposals on the table. Some
proposals are relatively complete, others require much more work to get them to
fit in.
The RS proposal describes the coding of PLS data and control signals.
The XGMII proposal describes an OPTIONAL physical interface consisting of 32
data bits, 4 control bits and one clock signal in each data direction.
The XGXS/XAUI proposal describes an OPTIONAL coding and physical interface
consisting of 4 serial signals in each data direction.
Calling XGXS/XAUI an "XGMII extender" is somewhat deceiving. If both the XGMII
and XGXS/XAUI are voted in as OPTIONAL 10 GbE interfaces, a 10 GbE device may
choose to implement XGXS/XAUI and not the XGMII. Such an implementation is
viewed by many as potentially being the most cost effective 10 GbE intra-cabinet
interconnect. Note that XAUI is viewed by its supporters (24 companies in
Albuquerque and more have signed up already) as a generic, low-cost,
chip-to-chip interconnect.
XGXS/XAUI goes a long way towards satisfying the 5th PAR criteria of Economic
Feasibility for the intra-cabinet interconnection portion of the 10 GbE
standard. Much more so than does the XGMII. This is because the XGMII is a high
pin count, high power (more termination resistors req'd), short distance,
non-jitter-attenuating interface.
I believe that the root issue in this discussion thread is whether 64B/66B
transports only /I/ or /A/, /K/ and /R/. If this is NOT the root issue then
please educate me. If you can please point out to me how in the world you save
anyone anything by transporting only /I/ I'll back down. Until then I'll
continue to use my 23 years of communications link design experience to push
what I believe to be the more cost effective and technically sound solution.
Best Regards,
Rich
--
Walter Thirion wrote:
>
> Rich,
>
> Without reiterating all of the points Ben made, I think the following
> paragraph from Ben really summarizes it:
> ______________________________________________________________
> The picture does tend to get confusing. However, if the XAUI
> is an extension of the XGMII, and the XGMII isn't "there" how
> can a XAUI be "there"? This does seem silly. However,
> architecturally, I think these layers are required to avoid
> a certain amount of confusion.
> ______________________________________________________________
>
> We have been using the XGMII as the architectural interface between the RS
> and the PCS. Granted it is optional and, therefore, implementors are free to
> use some other i/f. However, in the standard, we can't just assume magic
> happens between the layers, so the XGMII has been put in that role. If XAUI
> had been presented (and accepted) first, then maybe we would be having a
> different discussion.
>
> So I recommend we leave XGMII as the specified i/f and allow XAUI to
> transparently extend it. Transparently means you can't tell whether XAUI is
> present or not and, therefore, the PCS gets XGMII signals when XAUI is
> present just as it would when XAUI is not present.
>
> Walt
>
> > -----Original Message-----
> > From: Brown, Ben [BAY:NHBED:DS48] [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> > Sent: Friday, March 17, 2000 10:21 AM
> > To: rtaborek@xxxxxxxxxxx
> > Cc: HSSG
> > Subject: Re: XAUI and 64b/66b
> >
> >
> >
> >
> > Rich,
> >
> > It sounds like we intend to agree to disagree (or at least I do).
> >
> > Rich Taborek wrote:
> > >
> > > Walt, et. al.
> > >
> > > Jonathan and I just spent well over an hour on the phone
> > discussing various
> > > points of view on this issue. I'm sensing that one can view
> > this issue form
> > > verious perspectives including architectural purity, actual
> > implementations,
> > > standards documentation to ensure interoperability but not restrict
> > > implementations, etc.
> > >
> > > First of all, let me try to succinctly state the issue: Ben
> > is asking why
> > > 64B/66B coding needs to map XGXS codes instead of simply
> > mapping RS codes.
> > >
> > > I don't believe that it helps at all for any architectural
> > descriptions or
> > > standards documentation to describe the interface on the
> > PCS side of the the
> > > XGXS as the XGMII. I say this because I believe that we're
> > getting completely
> > > caught up in interfaces to interfaces. Both architecturally
> > and with respect to
> > > an implementation, the proposed Reconciliation Sublayer,
> > not the XGMII,
> > > generates the control codes associated with the MAC data
> > which is to be passed
> > > to the PCS. The proposed XGMII is 36 bits wide plus one
> > clock signal in each
> > > direction. If the optional XGMII extender is employed,
> > 8B/10B encoding converts
> > > RS codes to XGXS codes. These codes are transported across
> > XAUI to the remote
> > > XGXS. The XGMII itself is optional.
> >
> > Just as you state, the XGMII is optional. Therefore any extension of
> > the XGMII is, too. To go further, any control codes supported by that
> > optional extension are optional. That leaves us only with the control
> > codes of the RS. I understand and support that implementations may
> > choose to perform this extension and control code mapping. I just
> > don't agree with forcing this control code mapping by specifying to
> > it in the standard. Here again, we simply disagree.
> >
> > >
> > > At this point it is important to note that:
> > >
> > > 1) There is no architectural or implementation value in
> > reverse-translating the
> > > XGXS code to that of the RS for any PCS including Serial,
> > WWDM, Parallel Optics
> > > or MultiLevel;
> >
> > It sounds like your opinion is that for implementations
> > which use XAUI, it is a pain to translate back to RS
> > control codes. I might agree with that. However, for
> > implementations that don't use XAUI, it is more of a
> > pain to make that translation. Another disagreement?
> >
> > >
> > > 2) For the sake of architectural purity, there is reason to
> > place an XGMI
> > > Interface between the XGXS and PCS. For implementation
> > sake, XAUI extends the
> > > XGMII by attaching to the end of the XGMII not in the middle of it.
> >
> > Definitely a disagreement (attaching to the end and not sitting
> > in the middle, I mean).
> >
> > >
> > > 3) The XGMII is optional, the RS is not. If an
> > implementation chooses to
> > > implement XAUI and not the XGMII, should the architecture
> > and standard dictate
> > > that XGXS codes be reverse-translated to RS codes? If so,
> > should there be a
> > > second Reconciliation sublayer between the XGXS and RS? See
> > how silly this gets?
> >
> > The picture does tend to get confusing. However, if the XAUI
> > is an extension of the XGMII, and the XGMII isn't "there" how
> > can a XAUI be "there"? This does seem silly. However,
> > architecturally, I think these layers are required to avoid
> > a certain amount of confusion.
> >
> > A PCS needs to use the same control codes as the RS. If there
> > is an XGMII between them, cool. If a XAUI extends that XGMII,
> > even cooler. For parallel/CWDM if the PCS is identical to the
> > RS side XGXS, then implementations would certainly be unlikely
> > to go back and forth with control codes. However, the picture
> > should be clear, silly or not. Another definite disagreement.
> >
> > >
> > > 4) If indeed you still believe that the Serial PCS should
> > reverse-translated
> > > XGXS codes (/A/K/R/'s) into RS codes (/I/'s) and the stream
> > gets all the way to
> > > the optional Remote XGXS adjacent to the Remote PCS, this
> > XGXS must regenerate
> > > the XGXS codes to support XAUI. It's much simpler to not do
> > thia translation
> > > twice.
> >
> > I would argue that implementations which do not use XAUI
> > won't have to do it at all. Another disagreement.
> >
> > >
> > > At this point, I'd like to ask some questions?
> > >
> > > What's the big deal about having the Serial PCS, and
> > specifically 64B/66B
> > > transport (/A/K/R/) instead of (/I/)?
> > >
> > > What is the achitecture, documentation or implementation or
> > other useful reason
> > > for requiring a re-translation of XGXS code back to RS
> > codes at the PCS?
> > >
> > > What is the achitecture, documentation or implementation or
> > other useful reason
> > > for requiring an XGMII between the XGXS and PCS?
> >
> > I simply find it ackward to define a serial PCS encoding as using
> > control codes based on an optional interface. If the XAUI becomes
> > mandatory, then this makes sense. While the XAUI remains optional,
> > I simply can't support this. Obviously, a major disagreement.
> >
> > Ben
> >
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > Walter Thirion wrote:
> > > >
> > > > I don't know about Rich, but I definitely agree with you.
> > The interface on
> > > > each side of XAUI should be XGMII. If the implementer
> > chooses a different
> > > > i/f that is his choice.
> > > >
> > > > Walt
> > > >
> > > > > -----Original Message-----
> > > > > From: Benjamin J. Brown [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> > > > > Sent: Thursday, March 16, 2000 1:08 PM
> > > > > To: 802.3ae; Rich Taborek
> > > > > Subject: XAUI and 64b/66b
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Rich,
> > > > >
> > > > > Jonathan just sent me a note saying that I was even confusing
> > > > > him right now so I want to stop and ask my question again. I'll
> > > > > try to make this as clear as possible.
> > > > >
> > > > > In the layer diagram that Brad showed in Albuquerque, the XAUI
> > > > > was shown as an XGMII extender. To me this means that the
> > > > > reconcilation sub-layer speaks using XGMII language and the PCS
> > > > > listens using XGMII language. The XAUI can extend this interface
> > > > > by translating from XGMII to XAUI but it must translate back
> > > > > again before it gets to the PCS. The XGXS block is the
> > translator.
> > > > >
> > > > > The 64b/66b proposal as written ignores the XGXS block between
> > > > > XAUI and the PCS. It is my contention that, though this would
> > > > > work, it is unnecessary and even burdensome to those
> > implementors
> > > > > that choose to not use XAUI. 64b/66b would work equally as well
> > > > > without the XAUI specific control codes as they add nothing to
> > > > > the efficiencies of 64b/66b (that I can tell). The
> > XGMII specific
> > > > > control codes are completely adequate for 64b/66b. In
> > my opinion,
> > > > > a serial PCS should be specified as if XAUI didn't exist.
> > > > >
> > > > > I'll even go so far as to state that, in my opinion, even a
> > > > > parallel/CWDM PCS should be specified as if XAUI didn't exist.
> > > > > If this PCS turns out to be identical to the XGXS block
> > then some
> > > > > implementors may choose to avoid the encode/decode/encode as
> > > > > specified in the standard, but I believe that is how it should
> > > > > be specified.
> > > > >
> > > > > Is the question/comment still confusing or do you
> > merely disagree?
> > > > >
> > > > > 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