November 6, 1997

Driving the world of Gigabit Ethernet

Howard Johnson

In case you are wondering what we standards weenies do at all those meetings, here's a little peek into the standards process.

It was a wild summer! Most of my time was occupied working as chief technical editor of the new IEEE 802.3z Gigabit Ethernet standard. That standard, when complete, will advance the Ethernet operating speed to 1 billion, or 10⁹, bps.

This summer, the Gigabit Ethernet effort moved into its homestretch. We issued our first official IEEE working-group ballot about six weeks ago. This move signals the achievement of a significant technical consensus among more than 650 people who monitor and work with our standards task force. So far, we have received 1288 formal comments on this ballot, and we anticipate receiving a lot more between now and the time we finish, sometime in the spring of 1998.

Needless to say, I've been busy. In case you are wondering what we standards weenies do at all those meetings, here's a little peek into the standards process.

One of the key questions in front of our committee has been "How should we best specify the I/O performance of drivers for the Gigabit Ethernet parallel interface?" This interface, called the Gigabit media-independent interface (GMII), connects higher level computer-system chips to the physical transceivers you use to convey gigabit serial data. The GMII is a point-to-point, dual unidirectional interface, meaning that the specification defines one set of wires for use in the transmit direction and another separate set of wires for use in the receive direction. In each direction, there are eight parallel data bits, two control bits, and a clock, plus a few other signals. The interface is clocked at 125 MHz.

Clocking a unidirectional bus at 125 MHz is not difficult with today's logic. Ordinary CMOS circuits, at densities of 0.35 µm or less, can do the job, and many people have used them for such tasks.

The problem our committee faced, however, was not whether we could make such an interface work, but how to specify the interface so that many vendors could build it and all the parts would still be interoperable. You see, many different ways exist to get such a bus to work. For example, the four most popular methods are to constrain the driver source impedance, the end-termination impedance on the bus, the driver rise and fall time, or the bus length.

Early on, we determined that, to cover the range of physical topologies necessary to build useful products around this interface, the bus lengths would need to stretch more than 1 or 2 inches, which is pretty much the limit at this speed for the constrained-bus-length method. It became apparent that some combination of terminations and limited rise and fall time would be necessary.

At that point, our biggest obstacle was political, not technical. The various chip manufacturers all had different capabilities for rise and fall time, termination strategy, and output-impedance control. Some wanted to control reflections by implementing a well-controlled output impedance on the drivers. Others wanted to use a low-impedance driver with an external series termination resistor. Still others wanted to use a loosely controlled output-impedance specification, but with tight control over the rise and fall time. Any of the approaches could work, but which one could the committee choose? Any direction we turned, there was powerful opposition.

In the end, it was Bill Quackenbush of Cisco Systems (San Jose, CA) who came up with a way to specify the drivers that would allow each vendor to individually trade off its rise/fall time, termination technique, and driver output impedance. It is a simple, elegant technique. Faced with a similar problem, you might consider using it.

Quackenbush's proposal was to connect the driver to the near end of a 1-nsec, 50 ohm transmission line. Load the far end of the line with a 5-pF capacitor, which represents the receiver. If the manufacturer calls for a termination technique, use it as prescribed. Under these conditions, the waveform as you measure it at the receiver must fit within the proposal's prescribed waveform template, which limits the overshoot and transition time.

That's it. The proposal includes no explicit specification of rise and fall time, termination technique, or driver output impedance. The waveform at the receiver just has to fit within the prescribed template. His idea concentrates on the worst-case topology of interest (about 6 inches with a 5-pF load) and still allows the driver vendors to make their own design trade-offs. In practice, if a driver passes Quackenbush's test, it is highly likely to pass with shorter lengths and smaller loads.

His setup is a good specification technique and a far cry from the oversimplified "50-pF-load" specifications we are used to seeing for output drivers. If our committee had thought of it earlier, it wouldn't have been such a wild summer.

Acknowledgements

I would like to thank Packet Engines (Spokane, WA) for sponsoring my work on the Gigabit Ethernet-standard project.

| EDN Access | Feedback | Table of Contents |