RE: XAUI receiver characteristics
Dawson,
Thanks for your reply. Please find my responses inserted
below
> -----Original Message-----
> From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> Sent: Monday, October 16, 2000 21:01
> To: 'Haulin Tord'
> Cc: HSSG; Rudberg Björn
> Subject: 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?
OK I see how it is set up. Having a larger total jitter budget
for the transmitter is better than adding specified jitter
components. 0.3UI jitter due to frequency dependent
attenuation seems adequate for the 50cm distance range.
Jitter masks are difficult to specify and to measure. On top
of the jitter produced by the transmitter into a perfect termination,
we should account for contribution from reflections and folding
of common mode reflections into the differential domain. Could
all this and even the output impedance specification be replaced
by a jitter measurement at the end of one or two realistic load
models?
>
> >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."
Jitter tolerance specifications involve characteristics of the
data recovery. Is there a desire for the XAUI specs to avoid
going into specifications for this?
Where does the quote come from?
>
> >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?
Not very important really as long as read by humans only.
>
> >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?
The transmitter plus a lossy line can generate very short symbols
with very low amplitude, but not with independent timing and
amplitude variations.
>
> >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.
A higher allowed peak amplitude from the receiver will allow
more pre-emphasis and lower the risk of running out of other
margins.
>
> >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?
Yes. A good idea.
>
> >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
>