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

XAUI, XGMII extender?


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.


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