RE: Proposal: XGMII = XBI+
My 2 cents (American):
1. Joel Dedrick's paper described a painless (delay free) way to
produce a source synchronous clock with an ASIC. It assumed the presence of
a clock running at 2*155 or 311 MHz and the sourced clock simply came from a
flip flop toggled by the 311 clock. I don't know about ASICs, but with an
FPGA, the same technique can be used to painlessly produce a source centered
clock as well ... simply make the toggle flip-flip trigger on the negative
edge of the 311 while the data is registered on the positive edge. This
assumes you can tolerate the deviations in the 311 clock duty cycle that are
bound to exist.
2. On the receive side, I think the most robust FPGA solution would be
to run the received clock into one of many DLLs or PLLs available on FPGAs
to zero out the clock buffer delay. I would think a source centered clock
would have maximum margin. The PLL solution compensates for process corner
effects. My guess is that relying on the zero hold-time input delay
features would be much lest robust.
Bottom line, I'd support the "don't mess with XGMII" position.
Ted Speers
Strategic Marketing
Actel
> -----Original Message-----
> From: Brian Cruikshank [SMTP:brian.cruikshank@xxxxxxxxxxxx]
> Sent: Monday, September 25, 2000 8:33 AM
> To: rtaborek@xxxxxxxxxxxxx
> Cc: HSSG
> Subject: 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