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
--
-----------------------------------------
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
-----------------------------------------