RE: Proposal: XGMII = XBI+
Ted and Rich
Let me express my support in what you said (below), and add that Its just
the same about ASICs as well:
In the Transmit side:
You can generate the 156.25Mhz clock with the falling edge of the internal
312.5Mhz clock while all the data and control bits are generated with the
rising edge, and in this way achieve a half phase delay between the data and
the clock. This half phase delay is not generated by a "Delay Element" and
therefore do not tolerate 3 times between the best case to the worst case,
as Joel Dedrick presented.
In the receive side,
Just do the same, but this time within the DTE-XGXS chip. I think every body
agree that there is a 312.5Mhz clock as well.
I think that the conclusion is that if the source generates the delay, it
can do it without using "Delay Elements". When the destination generates the
delay, it has to use either DPLL which is complicated, or "Delay Element"
which is not accurate. Therefore, it is preferred to do it always in the
source.
Regards,
Boaz
> -----Original Message-----
> From: Speers, Ted [mailto:Ted.Speers@xxxxxxxxx]
> Sent: Tuesday, September 26, 2000 11:26 AM
> Cc: HSSG
> Subject: 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
>