Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: XAUI and 64b/66b

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. 

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;

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.

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?

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

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?

Best Regards,

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