Re: Proposal: XGMII = XBI+
Ladies and Gentlemen,
I agree with Howard Frazier's and Curt Berg's comments on this issue. I
have no concerns about the interoperability of the XGMII as specified in
the 802.3 approved baseline in FPGA or ASIC implementations. My company
has already looked at many variations of ASIC and FPGA technology
combinations, all of which are workable. Trading one parallel data and
control interface for another will not enable early 10GE products. In
fact, it will stifle early 10GE products. In going with the "If it ain't
broke, don't fix it" principle, I recommend rejection of any proposal to
change the XGMII unless it can be proven that a problem exists.
On a related topic, I am concerned about the New Orleans decision to
change the XGMII Tx and Rx clocks from both source centered to both
source synchronous. A careful analysis of this decision will show that
it only adds work to the implementer of XGMII parts on both sides of the
interface. In essence this change moves the burden of determining the
precise location of the clock from the transmit to receive side of the
interface with no apparent advantage. Since the XGMII is a full duplex
link, this change forces an implementer to change their implementations
(timings) on both the transmit and receive sides of the same device. I
won't go into detail on this tangential issue on this note, but I will,
upon request, in a new thread.
I advise against following the process by which this change was approved
in New Orleans in the future. In my view this is what transpired there:
1) We started with an XGMII clocking scheme which was not broken;
2) Joel Dedrick from PMC-Sierra proposed to change TXC (from MAC) to
source synchronous to ease TXC generation, but this was based on having
XAUI/XGXS on the PHY side. Since XAUI is optional, the proposed solution
is not universal and only complicates the XGMII specification;
3) Someone (I don't remember who) proposed a straw poll to consider all
four possible combinations of source synchronous and centered XGMII
clocking. The incumbent, symmetric source centered, lost out to
symmetric source synchronous in a big way, surprising the heck out of
me! All other options received either no or very little support;
4) All XGMII implementers are forced to change their implementations for
no apparent benefit.
The problem as I see it is that the end result was not a proposal which
had sufficient time air time, and it's implications were not well
understood. I believe that most if not all early implementers, including
myself, were affected by this change with no apparent benefit. I've
implemented the change, so I'm covered, but I worry that the change will
only delay other early implementations, again, for no apparent benefit.
Best Regards,
Rich
--
Howard Frazier wrote:
>
> I agree with Curt's comments, and would like to add:
>
> - The XGMII must be ammenable to common ASIC and FGPA design
> practices and tool flow and current process technology.
> The ability to rapidly design an ASIC or FPGA implementation
> of a 10 GE MAC or PCS is going to be of major benefit to
> those who want to bring 10 GigE to market quickly.
>
> - Over time, the XGMII disappears as an external interface,
> and gets buried inside a chip which integrates the XGXS
> or the SUPI PMA. In the long term (two years or so), the
> interfaces we care about are XAUI and SUPI, so we needn't
> concern ourselves with the long term viability of XGMII.
> We need to optimize it for today.
>
> Howard Frazier
> Cisco Systems, Inc.
-------------------------------------------------------
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