Re: XAUI, XGMII extender?
Walt,
I have never viewed XAUI/XGXS as REQUIRING the XGMII. XGMII has always been
proposed as an optional interface as was XAUI/XGXS. Therefore, XAUI/XGXS is
proposed as an additional interface. It was then located in the stack between
the XGMII and PCS.
I don't believe that there were ever any presentations made to the HSSG nor any
reflector discussion requiring an XGMII for XAUI. The only folks I ever hear
suggesting such a requirement are those that dislike XAUI/XGXS for one reason or
another, mostly because it's not SONET.
The XGMII and XAUI/XGXS directly follow the well proven and flexible 1000-BASE-X
architecture where both the GMII and TBI are optional. Requiring the XGMII is
not consistent with the evolution of 1 GbE products where the SerDes (PMA) has
moved into the MAC/PHY ASIC in many instances to reduce product cost and enable
higher port densities.
In the past year of HSSG work I have noted a strong desire for an inexpensive
and generic method of providing 10 Gbps chip-to-chip interconnects over PCB
traces available from a significantly large number of multiple vendors this
year. This interconnect goes a long way towards meeting the Economic Feasibility
PAR Criteria element. Please don't encumber it by REQUIRING that XAUI/XGXS be
placed somewhere into the architecture stack solely for the purpose of making it
more expensive than it needs to be.
Let's get down to the root issue here. This all started with Mr. Ben Brown's
questioning of coding /A/K/R/ in a 64B/66B subframe rather than just the /I/s
generated at the reconciliation sublayer. The XGMII actually has nothing to do
with the root issue. I'd much rather be helping Ben resolve this issue than
writing these notes :-)
Extending the XGMII with XAUI/XGXS just to provide another XGMII on the other
side is simply not optimal from an architecture or implementation viewpoint.
Early prototypes 10 GbE solutions may do this, but so what. They would be
standard compliant anyway since our current direction reflected in Brad's
documentation structure is to not specify the interface between the XGXS and
PCS. Therefore, it could be an XGMII. It seems that all implementations
envisioned about XGMII and XAUI/XGXS are allowed and standard compliant. I then
have to go back to the root issue in the last paragraph because I fail to see
another one. Please help!
Best Regards,
Rich
--
Walter Thirion wrote:
>
> Rich,
>
> I totally agree that no final decisions have been made with respect to
> interfaces, coding, etc. However, I think a consensus has been forming
> around XGMII with XAUI as a potential extender. To change at this point and
> propose XAUI as an additional i/f may be ok, but you need to recognize that
> it is different from the discussions we have been having.
>
> Walt
>
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxx]
> > Sent: Saturday, March 18, 2000 3:45 PM
> > Cc: HSSG
> > Subject: 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
> > >
-------------------------------------------------------
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