Re: XGMII clocks
Qzhao,
Please see my responses below.
qzhao wrote:
>
> > With two phase clocks you trade duty cycle problem against
> > managing two clocks and two paths. You still need to accurately
> > put the second clocks posedge in the middle, and you have the same
> > "duty cycle" distrotion on data. Not easy to put the 2nd pos edge
> > in the middle if you don't start with a 2x clock. Well if you have
> > a 2x clock then it is easy to generate a symmetric clock !
>
> 1) Yes, both data and clock will have duty cycle distortion problems.
> But once you have two-phase clock and you only use the same
> edge of each clock in the pair, then you don't care the distortion
> anymore for these two clocks, only data distortion affect timing.
>
> Lets do the timing analysis, we call the difference of rise and fall
> delay is Trf.
>
> - single phase clock DDR, data relative to clock timing will have an
> extra +/-Trf ( total is 2 * Trf) uncertainty. So the total timing
> margin will be reduced by 2 * Trf.
>
> - two phase clock DDR, data relative to clock timing will be have only
> Trf extra uncertainty. Timing margin is reduced by Trf.
Your analysis is correct but does not account for the phase/skew
difference between the two clocks. The question is how large this
difference is relative to Trf? If large, than the two-phase clock will
have an uncertainty of >2Trf.
> 2) Yes, for two-phase clock, you have an extra clock to manage, but if you
> can manage one clock, and you should be able to manage the second clock.
> Since all your timing care about is skew of each clock in the pair
> relative to the data. In single clock design, you have to manage the
> data and clock skew anyway. This price is worth to pay to get Trf extra
> timing margin if Trf is big (say 600 ps!).
Once again, the question is how large the two-phase clock phase/skew is
relative to Trf.
> 3) Yes, 2X clock will help to put the clock in the middle of the data if
> that is required by some PHY chips. But 2X clock will not help to
> reduce the duty cycle distortion problem if the distortion problem
> happens in the transmitter I/O section where the clock has already
> been divided down to 1X.
I don't believe that this is what is intended. If a 2X clock is
available, then it would be used as the XGMII clock. This is "standard"
clocking where the clock rate is twice as fast as the data, 312.5 MHz in
this case. Data sampling would occur on only one clock edge. According
to your calculations, the Trf uncertainty would not be applicable.
> > The max gitter between clock and data is what kills you.
>
> I don't know what is jitter mean here, if it means the clock jitter
> then not much can be done about it except finding a low jitter clock source.
>
> But if the jitter mean data and clock phase uncertainties from all
> sources including both rise and fall edges, that is exactly what we
> try to do to reduce that by Trf ( like 600ps) using two-phase clock vs single
> clock.
Finding a low jitter clock source is one way to skin the cat. Removing
data and clock uncertainties is a difficult thing to One way to do it is
to have the XGMII receiver perform precise phase positioning by
attenuating jitter in received clock.
> > It is not enought to run best case and worst case sims, instead
> > weak p strong n, and strong p weak n, will make your make your
> > live difficult. Basically standard ASIC STA is not useful to analys
>
> Yes, I agree all possible process corners should be simulated.
> I also think a good process will have n and p correlated. p and n
> process skew will most likely make duty cycle distortion problem worse.
Absolutely.
> > this problem ! Most bang for the buck is a lower voltage swing,
> > and more matched impedance. All high speed SRAMs, with DDR (that I know
> > of) have gone to HSTL, with impedance controlled drivers for very good
> > reasons !!
>
> SSTL type -1 is used in XGMII interface. Depend on whar type of HSTL
> to use, it may or may not have lower swing. However, lower swing can only
> help to reduce the rise and fall time difference, not the difference between
> rise and fall delay. Part of the duty cycle distortion are due the rise and
> fall delay difference thru the I/O driver/receiver.
The rise and fall delay is what I refer to as phase/skew differences
between any two signals including all differences imparted by the I/O
driver and receiver
> Qin Zhao
> Cisco Systems
>
> >
> >
> > -Curt Berg-
> > Extreme Networks
> >
> > -----Original Message-----
> > From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
> > Sent: Friday, September 08, 2000 10:01 AM
> > To: Jonathan Thatcher
> > Cc: stds-802-3-hssg@xxxxxxxx
> > Subject: Re: FW: XGMII Clocks
> >
> > Rich,
> >
> > At 10:07 AM 09/07/2000 -0700, you wrote:
> > >
> > >Forwarded in behalf of Rich Taborek.
> >
> > >> 2) Changing to a two phase clock: This doesn't help with duty cycle
> > >> variation at all and nominally makes it worse.
> >
> > The two phase clock do releive the duty cycle problem.
> > Because with one varying duty cycle clock the
> > data tracks with the edges but only one edge of the
> > clock moves back and forth. And that will shrink one data valid
> > window and stretch the other data valid window in one clock period.
> > So with min pulse width the hold time will suffer
> > and with max pulse width setup will suffer.
> >
> > And this also means that the duty cycle variation
> > of the clock have to be very tightly specified.
> >
> > Thanks
> > -Sanjeev
> >
> > >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
> > >>
> > >
--
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