RE: XGMII Clocks
** NOTE: For those of you that have seen this
** email, please disregard. David asked me to
** reword part of it because one line tripped up the
** email-filter program.
Hi Jonathan and Rich,
a couple more points in favor of differential clocks.
First off, if the clock is differntial, then it generates far
less EMI than a single-ended clock of the same frequency and
amplitude. This is because you have complementary fields for
the true and complement signals which negate each other.
The second item is that you can actually find a number of
standard products which make use of a differential clock
and single-ended data. Take a look at the OIF standard parallel
interface for OC-48 PHYs. The OC-48 PHY uses a 16-bit
parallel PECL bus, with a differential PECL clock (running at
155 MHz). And if I recall correctly, the OC-192 PHY definition
uses a 16-bit VLDS parallel bus with an LVDS DDR clock (622 MHz).
And as I stated in my earlier email, you also get the added
advantage that the clock reference is not corrupted or modified by
power supply noise or data-induced crosstalk.
Regards,
Ed Gricna
Cypress Semiconductor
> Rich,
>
> A couple of points regarding the concept of differential clocks.... see
> below.
>
> 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.
>
> --split--
>
> This would only be true if the clock drivers rising and falling times and
> logic threshold crossings were equal and not affected by power and
> temperature variations. The fact is that a differential drive is
> significantly more immune to these variations.
>
> > Since the I/O buffers for data and
> > clock would be different, the inherent tracking of data to clock would
> > be worse.
>
> --split again--
>
> I don't know how to make this jump... The clock and data are already
> inherently different. In one way or another, the clock is running at twice
> the rate the data is.
>
> > 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.
>
> --split again--
>
> But, for all the reasons you list that the two phase clock is not good a
> differential clock excels.
>
> > Seems to be a disadvantage to the way it is. For this
> > disadvantage, the
> > cost is one extra pin.
>
> So, (for the differential clock), we agree that this may have not been done
> before. Neither are many of the other things we are doing in this standard's
> effort.
>
> Bottom line: is the improvement in EMI, jitter, stability, etc. worth the
> price of a pin?
>
> This is something that some SPICE jockeys should be able to demonstrate with
> some simple simulations. Takers?
>
> >
> > 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
> >
------------- End Forwarded Message -------------