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

Re: XAUI/XGXS protocol


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: 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      |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Best Regards,
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