Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All,
In Ottawa Stuart Robinson presented a proposal to
paste the "OIF interface" (SFI-4 interface, OIF1999.102), see http://grouper.ieee.org/groups/802/3/ae/public/may00/robinson_1_0500.pdf
into .3ae
The idea of reusing the work done by the OIF and
the devices developed to meet their specification agrees perfectly with the cost
and time-to-market objectives of .3ae. However, in the LAN PHY case, a minor
change has to be made in the 10GE version of the OIF interface:
The OIF specifies both data and clocks at the
16-bit interface. The reference clock is specified to be 622.08MHz (for OC-192
rate). In the LAN case (64b66b) this translates to 644.53MHz. Thus, the
clock-multiplier ratio is x16. The specification allows other optional reference
clocks e.g. 311MHz (x32).
In my mind these reference clocks are too fast for
10GE. Fast refck's means bulky and expensive oscillators. In addition using
644.53MHz refck adds an entirely new clock-domain in the PHY, requiring
additional clock tolerance compensation (see below). For Ethernet we obviously
need cheap and small.
If the OIF interface is included in 802.3ae as an
optional PMA interface we should do one of the following:
1) not specify the reference clock allowing this to
be implementation specific
2) specify a slower reference clock
Actually I like both options. Those who like option
2, please consider the following:
In a serial LAN PHY you need the following
clocks:
312.5MHz or 156.25MHz for XGMII (or 3.125GHz for
XAUI)
156.25MHz for the 64 and 66 bit wide interfaces in
the 64b66b CODEC (PCS)
644.53MHz for the 16-bit (OIF) PMA
interface
10.3125GHz (line rate)
some of these clocks are needed in both a receive
and a transmit version.
The OIF specification implies that the 644.53MHz
interface clock should be sourced from the SerDes. Thus the SerDes generates
both transmit and receive version of the 644.53MHz and the 10.3125GHz
clocks.
Looking at the list above, 156.25MHz becomes an
obvious choice as reference clock. This implies that the SerDes clock-multiplier
should be x66, requiring a 10GE specific version of the OIF-style
SerDes.
If you want to implement a serial LAN PHY using a
"pure" OIF SerDes (644.53MHz refck), the 156.25MHz PCS clock should be generated
by the PCS chip or sourced from an additional crystal. The former requires an
extra PLL on-board the PCS chip and the later increases device count and
requires clock tolerance compensation.
Thus, either way you're in trouble. You can choose
to specify a 644.53MHz reference and reuse OIF SerDes. This complicates PCS
design and in some implementations require an additional crystal reference. You
can also choose to let the SerDes do the job, but then it is no longer a
standard OIF SerDes.
Being a SerDes designer, I think that the handling
of this odd-ratio clock rate conversion is best done in the SerDes. From a total
PHY cost and complexity perspective adding an extra crystal reference (in
addtion to an already expensive one) or generating 156.25MHz from 644.53MHz
inside a CMOS PCS chip makes little sense. The only thing gained would be the
ability to reuse OIF SerDes. Modifying OIF SerDes to include Ethernet specific
clock generation is a minor task that will give us a lower complexity
(cost, power) LAN PHY.
THE BOTTOM LINE:
Specifying an OIF reference clock of 644.53MHz
increases serial LAN PHY complexity significantly. The reference clock should be
left unspecified of specified at 156.25MHz (or half: 78.125MHz).
Stuart:
If you consider this a "friendly amendment", please
update your proposal and I'll be happy to endorse it for July.
Regards,
Henning
-----------------------------------------
Henning Lysdal
Design Engineer
GiGA A/S - an Intel Company
Mileparken 22
DK-2740 Skovlunde
Denmark
Tel.: +45 70 10 10 62, Fax: +45 70 10 10
63
Direct: +45 44 54 61 54
E-mail: hl@xxxxxxx
Web: www.giga.dk,
www.intel.com
|