All,
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