Optional PMA interface (OIF)

["Henning Lysdal" <henning_lysdal@xxxxxxxxxx>]

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