Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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