RE: XGMII Clocks
Hi Howard,
One of the big problem with XGMII is the large voltage swing
of SSTL. It would be of great benefit to use a different interface
standard that is more compatible with today's ASIC technology.
(Moving forward most ASICs will use 1.2-1.8 V core, and
having 2.5V I/O is painful.) If we reduced the swing, power consumption
will drop, timing gets easier, and EMI should be cut significantly.
We have done significant SPICE simulations of SSO, ISI, of DDR interfaces
like XGMII, and lowering the swing definitely gets much better eye pattern.
I would be willing to help writing a proposal for standard that use
HSTL, with extended VDD, so you could also use 1.8 V LVTTL/HSTL.
Anyone else that would support this ?
Having two clock make little impact on the timing budget, and you would
have to match two clock paths instead of one. Asymmetry comes mainly
from level shifting and that your internal threshold is different form
Vref. Much better again would be to minimize level shifting be using
a lower external swing. Hopefully it helps you both on the MAC and
PHY side.
-Curt-
-----Original Message-----
From: Howard Frazier [mailto:hfrazier@cisco.com]
Sent: Wednesday, September 06, 2000 9:30 AM
To: stds-802-3-hssg@ieee.org
Subject: XGMII Clocks
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.