Re: XAUI/XGXS protocol
Mike Jenkins wrote:
>
> Rich,
>
> Thanks for the reply. I was trying to discern the definition of XGXS.
> Your replies (below and to others) say, I think, that XGXS/XAUI/XGXS
> is not, in fact, a symmetrical interface. So it ought to be renamed
> with an additional function (XGXS/XAUI/somethin' else).
Mike,
XAUI is an coded interface. The CODECs are defined to be in the XGXS at each end
of the XAUI. Therefore, XGXS/XAUI/XGXS is symmetric. What is not symmetric is
that the XGXS/XAUI/XGXS is not intended to sit "in the middle" of the XGMII so
the notion of XAUI as a XGMII "extender" is not altogether appropriate for those
individuals that can only envision an extender as something that goes in the
middle. Most 10 GbE implementations will likely include one of the following:
1) XGMII as short PCB traces to a chip implementing XGXS with long PCB traces to
another chip which includes another XGXS and a PCS...;
2) XGXS integrated in with the MAC and RS with long PCB traces to another chip
which includes another XGXS and a PCS...
> I see your argument about the alignment characters being useful to
> some PCS/PMA/PMD implementations. Yet, things are getting sticky.
> Wouldn't it be simpler to specify XGXS/XAUI/XGXS symmetrically?
It is, see above.
> Then, if some PCS/PMA wanted to use these characters, the design
> (presumably contained within one chip) could collapse (i.e., remove)
> the redundant, reciprocal functions of deleting and re-adding these
> alignment characters?
Yep, this is noted above in both (1) and (2). The only question is the level of
integration desired by the equipment vendor. This is usually a
cost/complexity/time to market tradeoff.
> Regards,
> Mike
>
> Rich Taborek wrote:
> >
> > Mike,
> >
> > Comments below:
> >
> > Mike Jenkins wrote:
> > >
> > > Rich,
> > >
> > > I'm confused. I will list what I think I've heard. Please let
> > > me know where I missed something:
> > >
> > > * XGXS/XAUI/XGXS is proposed as an optional XGMII extender.
> > > That is, XGMII in and XGMII out.
> >
> > You're implying that XGMII is required and it's not. The GMII was optional in
> > GbE and the XGMII is proposed as optional for 10 GbE. In the case that both are
> > implemented, are you suggesting that the PCS-side XGMII is a 74 signal
> > interface? Clearly it would be optional. Is anyone out there planning to
> > implement this second XGMII (between the XGXS and PCS) and actually featuring
> > it? If not, it shouldn't be documented this way in the standard.
> >
> > > * The XGXS /A/ character (at least, and maybe others) is not
> > > a part of XGMII protocol, I believe. But you are proposing
> > > leaving it in the data stream, encoding it, and shipping it
> > > out thru the PMD.
> >
> > /K/ or /R/ are neither part of RS protocol nor transported across the XGMII. The
> > Reconciliation Sublayer only generates /I/'s.
> >
> > XGXS, XAUI and XGMII are supposed to be PMD independent. A WWDM or Parallel
> > Optics PMD requires its PCS to support /A/, /K/, and /R/ to perform
> > synchronization, deskew, alignment and clock tolerance compensation. This
> > information must indeed be transported out through the PMD to enable the remote
> > PCS receiver to perform all of the latter functions. Per my Albuquerque
> > XAUI/XGXS proposal:
> > http://grouper.ieee.org/groups/802/3/ae/public/mar00/taborek_1_0300.pdf slide 4,
> > the XGXS acts as the PCS/PMA agent. Shipping /A/ over a Serial PMD does not
> > affect the throughput, complexity, etc. of the Serial PMD over and above
> > shipping /I/ but it certainly simplifies the task of the remote PCS in the case
> > XAUI is present there.
> >
> > > * Any device at the other end, then, must deal with such
> > > additional character(s), whether it employs XGXS/XAUI or not.
> >
> > For WWDM and Parallel Optics, this is required anyway. For the other PMDs it
> > causes no pain whatsoever. You want to see pain, think of what you'd have to do
> > at the remote end if the PMD is WWDM and the PCS is SLP to the XGMII (see the
> > earlier notes in this thread).
> >
> > > It seems, at minimum, that the XGMII definition must be expanded
> > > to include any extra characters defined in XGXS/XAUI.
> >
> > Not at all. The XGMII is a physical interface anyway. It's the Reconciliation
> > Sublayer that defines codes.
> >
> > Notwithstanding, the RS speaks Idles only. Only Idles need be transported across
> > the XGMII. Why do you say that the XGMII needs to know anything about
> > XGXS-specific extra characters? Is this specifically because of your view that
> > another XGMII must exist between the XGXS and PCS? If it hurts, don't do it.
> >
> > > Alternately, XGXS/XAUI should clean up what extra characters it
> > > inserted in order to deliver the same data stream it was entrusted
> > > to 'extend'.
> >
> > This is correct going from XGXS to the XGMII in the RS direction. In the XGXS to
> > PCS direction, the PCS should just carry the special codes all the way up to the
> > XGMII on the remote end.
> >
> > > Otherwise, this is like Microsoft's integrating their browser with
> > > Windows -- all of a sudden you get it whether you want it or not.
> > > Am I wrong? Please help me understand.
> >
> > I use Windows '98 and Netscape. Works just fine for me :-)
> >
> > > Thanks,
> > > Mike
> > >
> > > ...
> > > > I view XAUI as being a very prevalent 10 GbE interface,
> > > > perhaps not as prevalent as the serial side of the GbE
> > > > Ten-Bit-Interface. Barring no other complete and workable
> > > > XAUI/XGXS proposals that meet the requirements of an
> > > > optional XGMII extender, my view is that the PCS should
> > > > accommodate the optional XGMII extender as well as operate
> > > > properly without one.
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Jenkins Phone: 408.433.7901 _____
> LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
> 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
> Milpitas, CA 95035 http://www.lsilogic.com |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
Best Regards,
Rich
-------------------------------------------------------
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