FW: XGMII Clocks
Forwarded in behalf of Rich Taborek.
jonathan
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Wednesday, September 06, 2000 9:44 PM
> To: Jonathan Thatcher
> Subject: Re: XGMII Clocks
>
>
> Jonathan,
>
> Can you post the following note to the HSSG reflector for me? I've
> posted it twice today and neither copy made it to the
> reflector. I never
> got my copy and it's not in the archives.
>
> --
>
> Howard, et. al.
>
> My simple-minded 2 cents about XGMII clocking:
>
> 1) The way it is: The XGMII baseline defines single-ended
> data lines and
> clocks in both data directions. The clocks are DDR and are subject to
> duty cycle variations. The primary benefit of using DDR
> clocks seems to
> be EMI. The I/O buffers for data and clock would seem to track (i.e.
> cancel) each other over process and temperature.
>
> 2) Changing to a two phase clock: This doesn't help with duty cycle
> variation at all and nominally makes it worse. EMI would be
> worse since
> there are twice as many of the same EMI sources. Seems to be a
> disadvantage to the way it is. For this disadvantage, the cost is one
> extra pin.
>
> 3) Changing to a differential clock: The source of the differential
> clock is likely to be single-ended with duty cycle variations. The
> resultant differential clock would be subject to the same duty cycle
> variations as a two phase clock. Since the I/O buffers for data and
> clock would be different, the inherent tracking of data to clock would
> be worse. I'm assuming that what is meant here is that only the clock
> would be differential, not the data. Otherwise, double the number of
> XGMII signals to 148 from 74. I know of no other standard or proven
> interface where the data is single-ended and the clock is
> differential.
> Seems to be a disadvantage to the way it is. For this
> disadvantage, the
> cost is one extra pin.
>
> 4) Precise phase positioning: This is essentially what Joel Dedrick
> suggested in his reply to this thread. It requires a PLL on
> one or both
> side of the XGMII interface to sort out where to sample the data. This
> does NOT mean that an XGXS or XAUI is required. It just so
> happens that
> the XGXS implementation contains one or more PLLs. This
> technique would
> be applicable to XGMII DDR, two phase, or differential clocks.
>
> Bottom line is that a DDR clock seems adequate and when stretching
> things, one may need to add a PLL or two to ensure interface
> robustness.
>
> Best Regards,
> Rich
>
> --
>
> Howard Frazier wrote:
> >
> > In a previous email thread, we debated the merits of using
> > a single clock in each direction on the XGMII, versus using
> > 4 (frequency locked, but phase independent) clocks in each
> direction,
> > with a clock dedicated to each of the four "lanes".
> >
> > Without repeating the discussion, it is safe to summarize that
> > the majority opinion (from among those who expressed an opinion)
> > was to stay with one clock in each direction.
> >
> > So, I would like to toss out another question for your
> consideration.
> >
> > Should we use a two phase clock? Clock and ClockBar?
> >
> > Some designers have suggested that this will make the ASIC and
> > system timing more managable, because it is difficult to get
> > symetric drive strengths from the clock output buffers, and
> > the asymetry degrades the timing. With a two phase clock, you
> > would still have asymetry on the data signals, but at least
> > you won't have to account for the asymetry on the clock.
> >
> > At first blush, this seems like a modest addition. One more pin
> > in each direction.
> >
> > Any opinions out there?
> >
> > 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
>
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> 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
>