XAUI electrical issues
The D1.0 draft of clause 47 was discussed for two hours in the logic track
and for another two hours by sixteen particularly interested individuals in
the XAUI electrical breakout session at the plenary meeting in New Orleans
last week. (Thanks to Ben Brown for providing time and space for the XAUI
electrical breakout meeting.) The following issues were resolved. All of
these appear to be in the vein of the original XAUI presentation or very
minor modifications thereof, so I intend to incorporate them into the next
revision of the draft. Feel free to contact me directly or via the reflector
with any concerns.
1. Transmitter transition times are recommendations, not requirements. There
does not appear to be any reason to increase the maximum from 131 ps since
a) 131 ps is the 20-80% transition time of a sine wave at 1.56 GHz and b)
the numbers are only recommendations.
2. Both transmitter and receive impedances are defined by the 10 dB return
loss requirement. There does not appear to be a need to define DC
"impedance" as 100 ohms since a) it contradicts the return loss requirement
due to normal parasitic capacitances and b) it is not directly measurable if
AC coupling capacitors and resistive terminations are both integrated into
an IC.
3. "Transmit equalization" is a better term than "pre-emphasis" for the
standard.
4. The transmit total jitter requirement of 0.35 UI is a peak-to-peak number
including random jitter for a 10e-12 BER.
5. The load for measuring transmit characteristics is a 100 ohm resistor.
6. AC coupling is done at the receiver. AC coupling does not necessarily
need to be capacitive (though in practice it is likely to be!) and that any
capacitor value should be left to the implementer. (Recent reflector
discussions of likely implementations and practical capacitor constraints
are still perfectly appropriate.)
7. Receiver input impedance and receive-end link compliance include the
effects of the AC coupling since a) AC coupling is specific to the receiver
implementation and b) it may physically reside inside an IC in some
implementations.
8. A corner frequency needs to be recommended for receive jitter tolerance.
9. The receive link compliance eye opening should be hexagonal (vs. a square
or diamond).
10. PCB and connector impedances are recommendations, not requirements.
11. Hot swap capability is not considered to be important and does not need
to be detailed in the standard.
There are several larger issues that still need to be resolved. I encourage
open discussion on the following. Please let me know if there are other
issues you think need to be added to this list.
1. The present definition of driver characteristics cannot be measured in
practice. For example, how is the 100% amplitude level defined for complex,
non-trapezoidal waveforms? This currently affects the amplitude and skew
measurements. Is there a way to measure skew without relying on amplitude
definitions?
2. It was generally supported in the breakout session that only min and max
limits should be required on transmit amplitude, independent of
equalization. These limits could be defined in a table or by a transmit
template. Overshoot needs to be considered. The maximum transmit amplitude
is lower than some would like to see. One proposal was to allow 1.6V instead
of 1.0V for Fiber Channel compatibility.
3. The details of the receive eye opening need to be defined. Is 175 mVp-p
vertical opening enough in practice (assuming reasonable allowance for
timing jitter)? Where do the corners of the hexagonal opening belong?
4. The link over which the receive eye is to be measured is currently
undefined. Does it need to be defined? If so, how?
5. Receive skew is not measurable as currently defined. How can it be
defined and measured for an indeterminate waveform? (Similar issue to
transmit skew in #1, above.)
6. What value should be used for the receive jitter tolerance corner? (See
#8 in the list of resolved issues.)
7. The informational link budget is incomplete. It needs to be filled in if
it is considered useful.
8. Other issues?
Dawson Kesling
Intel Corporation
dawson.w.kesling@xxxxxxxxx
916 855-5000 ext. 1273