RE: XAUI receiver characteristics
Tord,
Thank you for the comments. Here are some replies and questions. I welcome
your your thoughts on the following and hope others will also chip in.
>I think the distribution of the jitter budget with 35% for the
>transmitter and 30% for line does not reflect what can be
>achieved in a given technology. The transmitter jitter should
>be limited to 0.1UI to allow more headroom for the receiver.
The Gigabit Ethernet transmit eye has a 0.25 UI (200 ps) opening, and the
2.5G Fibre Channel has a 0.3 UI (120 ps) opening. XAUI was chosen by a
consensus of SERDES vendors about a year ago to have a 0.35 UI (112 ps)
opening. I think other people would like to increase this, but I don't know
if they will be willing to take it from the transmitter budget. What do you
think can be achieved by the transmitter and what technology are you
thinking of?
About half of the transmit jitter budget of 0.35 UI was allocated for
deterministic jitter (DJ) and half for random jitter (RJ). The total RJ of
0.17 UI requires a 1-sigma random component of about 4ps. Some people
consider this tight for CMOS, particularly on the same die with several
other XAUI ports and a lot of MAC logic. How would you allocate the 0.1UI
proposal between DJ and RJ? Could the resulting RJ be practically realized
in all technologies?
>The far end template of figure 47.4 does not say much about
>the difficulty of data recovery unless accompanied by a jitter
>frequency distribution limit.
Assuming the 0.65 receive jitter number for now, would the following satisfy
your concern? If not, can you propose something?
"The XAUI receiver shall have a peak-to-peak jitter amplitude tolerance of
0.65 UI. It is recommended that the tolerance be at least 6.5 UI below TBD
kHz."
>The receiver input parameter limits given in table 47.2 is a mixture of
>requirements on the receiver and on the input signals to the receiver.
>For ease of use that should be changed requirements on the specification
>of a compliant receiver.
>Thus we should have an upper limit for the minimum input amplitude
>specification of a compliant receiver (e.g. 175mV).
I think that I understand your concern, but I do not understand its
importance. Can someone help me?
>To be meaningful, this
>requirement must be supplemented by time domain conditions on the
>input signal and some criterions for receiver function. The requirements
>on the receiver would be unnecessary high if the far end template of
>figure 47.4 would be interpreted as demanding the receiver to handle
>0.65UI high frequency jitter (112ps symbols)
I think it is unreasonable to interpret the receive eye this way since any
transmitter which generated such a pulse would not be compliant. However,
someone else has raised the same concern as you. How can it be clarified?
>Likewise, there should be a lower limit for the spec point for maximum
input
>amplitude of a compliant receiver. It would be advantageous to increase
this
>limit from 1V to 1.5V.
Can you list reasons why this is advantageous? Good reasons will help to get
a "yes" vote from the group in Tampa. By the way, someone else proposed 1.6V
in New Orleans and it was generally well received.
>For ease of implementation the upper limit on differential input impedance
>can be increased quite a lot without significant impact on the jitter. At
least
>to the geometrically symmetric 125 ohm level (relative to 80 ohms).
>Proposal: use 130 ohm as an upper limit.
There is a return loss requirement of 10dB. (This was accidentally omitted
from the receiver requirements in D1.0.) The impedance number was intended
by the originators to apply to the terminating resistance. 20% was chosen to
account for IC process variation for on-die termination. I would like to
remove the impedance number and use only return loss. 10dB should cover your
concern, shouldn't it?
>In clause 47.3.4.2 the return loss is required to be less than -10dB but in
>table it is given as a minimum requirement.
You are right that this was inconsistent. It has been corrected so that
return loss is being treated as a positive number.
>Is the input differential skew parameter really needed, or covered by other
>spec points?
I do not think it is covered by other spec points. I'm not sure why it was
included by the original HARI group. Do you know of some concern with it?
Can a HARI participant give some background or justification for the skew
requirement?
>While working with the standard, it would be good to have a couple of more
>columns in the specification tables. One with a justification for the spec
>point,
>and one with reference to related spec points. This will make it easier to
>make a consistent spec and to keep track of the implications of proposed
changes.
I would like to hear your specific ideas.
Thank you again, Tord. I look forward to your response.
-Dawson