XAUI, XGMII extender?
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
> >