Re: XAUI receiver characteristics
Hi,
I think it might be also beneficial to define what pk-pk jitter is at
the receiver from one bit to the next, i.e. at high frequencies -
3.125G/2. Does it mean that:
1. A single received bit can shrink to 0.35UI - 112 ps? (not surely
practical given the transmitter spec?)
or
2. Over a pair of received bits, one bit can shrink to 67.5% of nominal
bit (216 ps) and the next bit can stretch to 132.5% of a nominal bit
(424ps), giving an overall jitter between the pair of 0.65 UI? Another
way of describing this is a receiver must successfully land a single
occurrence of a 1 as long as 132.5% or as short as 67.5%. This leads to
a definition of pk-pk jitter as
(maxBitTime - minBitTime)/nominalBitTime e.g. 132.5-67.5/100 = 65%.
An eye diagram builds up an aggregate picture over many thousands of
bits. If in that sample size, one bit stretched and another bit shrunk
by half pk-pk jitter, it would result in an eye opening of 0.35 UI. It
would not necessarily mean however that any bit had shrunk by 0.65 UI.
A jitter mask describing amplitude of jitter versus frequency from 100hz
to 3.125G/2 would be helpful.
- Anne
"Kesling, Dawson W" wrote:
>
> 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