Re: Proposal: XGMII = XBI+
Rich,
I also agree with Howard Frazier's comment. XGMII is a short term solution
for all devices. XAUI is probably the long term solution.
However, I think that source synchronous can be easier to implement than
source centered. It depends on the device that you are implementing in.
On the receive input side: If you are in an ASIC, there is a clock tree
between the receive clock and the receive FF clock pin inside the device.
This causes a inherent delay shift. Source synchronous input is easier.
This can be part of the delay needed. If you want source centered, this delay
shift must be removed. You have to add this same delay to all the data
lines. This can be done fairly accurately by adding the same clock tree gates
or by adding the same delay that tracks over process. This is sometimes done in
FPGAs automatically.
From an FPGA data sheet:
An optional delay element at the D-input of this flip-flop eliminates pad-to-pad
hold time. The delay is matched to the internal clock-distribution delay of
the FPGA, and when used, assures that the pad-to-pad hold time is zero.
On the transmit output side: If you are in an ASIC, there is a clock tree
between the clock source and the transmit FF clock pin, but probably not to the
output clock pin. This causes no delay. Source synchronous output is easier.
If you want source centered output, a delay must be added.
Somewhere a delay must be added if both the transmit and receive side will
communicate with each other without PCB trace delay. With Source Synchronous,
it is in one place. With Source Centered, it is in two places. In an FPGA,
this may not be obvious, but it is happening.
Both methods will work, but having delay in only one place should add better
margin. The best margin would be to place the delay on the PCB, but this may
not be necessary.
/Brian Cruikshank
Rich Taborek wrote:
>
> 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