Re: XGMII Clocks
Jonathan,
Thanks for posting the note. Apparently I hit upon a magic word in my
note that caused the IEEE span filters to shoot the note down. I'd like
to continue discussion on points I made and you responded to:
Jonathan Thatcher wrote:
>
> > 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.
>
> 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.
I think we're talking two different issues here. My point is that the
XGMII DDR clock rate is 156.25 MHz with DDR and that the duty cycle is
not 50%. The data signals are single ended. I'm assuming that the
reference oscillator is either at 156.25 (doubtful) or multiplied up
from some slower frequency. If a differential clock output buffer is
implemented, source of the clock signal to the differential buffer would
likely be single-ended and subject to the same non 50% duty cycle.
Driving the differential clock output buffer with the non 50% duty cycle
input will result in a differential output whose alternating periods
likely do not match. I called this a "duty cycle variation".
Unless the differential clock output is generated from a reference clock
faster than 156.25 MHz, such as 312 MHz, I believe that a differential
clock will provide no better symmetric reference to the data than will a
single-ended clock.
I agree completely that differential drive is significantly more immune
than single-ended to power and temperature variations, but if it can't
pinpoint the center of the data any better than can a single-ended
clock, then it's not worth the extra pin.
> > Since the I/O buffers for data and clock would be different,
> > the inherent tracking of data to clock would be worse.
>
> 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.
No. That's exactly the problem. With DDR, the clock is running at the
SAME rate as the data. Rise and fall time differences contribute
significantly to the duty cycle distortion of the clock since they are
likely to be unequal.
As far as tracking goes, what I mean is that the design of single-ended
and differential I/O buffers in CMOS is significantly different. When
using the same I/O buffers, say all single-ended for clock and data, you
cannot DEPEND on the clock signals behaving just like the data, but
their behavior will likely be similar. If the I/O buffers for the data
are different from the clock, you can probably forget about any
dependencies between the two. What is important above all is the
location of the "center" of the data. Frankly, I don't see how a
differential clock helps me do this.
I'm all ears though, so clock experts should feel free to chime in and
convince me that I'm wrong.
> > 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.
The differential clock excels significantly with respect a single ended
clock in its noise and power supply variation immunity. The received
differential signal can be considered to be completely independent of
the simultaneous switching effects of the parallel data bus. However,
this also compounds the timing problem. If the clock is independent of
the data, then it's harder to find the center of every data bit. It is
likely that a single-ended clock based on the same I/O buffers as the
data will track the data better than can a differential clock can track
single-ended data.
> But, for all the reasons you list that the two phase clock is not good a
> differential clock excels.
But the differential clock only excels at characteristics that are not
relevant to accurate data tracking.
> > 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.
It looks like Ed Grivna has identified interfaces which utilize
single-ended data and a differential clock, so I'm wrong about the
existence proof. However, this does not necessarily mean that it's a
good idea. What needs to be proven is that a differential clock
SIGNIFICANTLY increases timing accuracy over a single-ended clock for a
single-ended data bus. I don't see the light.
> Bottom line: is the improvement in EMI, jitter, stability, etc. worth the
> price of a pin?
The answer is ABSOLUTELY YES. However, a differential clock would
certainly improve EMI over either a single-ended or two-phase clock but
I question any benefit with respect to jitter and stability. Off hand, I
would say that the EMI improvement alone is not worth the cost 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
> > 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
-------------------------------------------------------
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