FreeLists / si-list / [SI-LIST] Re: Jitter transfer vs. accumulation

["Chris Cheng" <Chris.Cheng@xxxxxxxxxxxx>]

I would say anything less than a very negative db is a large jitter in UI. 
Remember, jitter transfer is the ratio between the input jitter vs. the output 
jitter. Jitter induced by the power supply is relative to the UI.
And if jitter accumulation is such a small issue, no one will dictate these 
isolated everywhere PLLVDD and multiple sets of ferrite/R/C filters per chip 
just to quiet down the PLL.
 
________________________________

From: Paul Levin [mailto:levinpa@xxxxxxxxxxxxx]
Sent: Tue 3/13/2007 9:51 PM
To: Chris Cheng
Cc: si-list@xxxxxxxxxxxxx
Subject: Re: [SI-LIST] Jitter transfer vs. accumulation



Dear Chris,

Unless something is horribly wrong with the PLL, the jitter peaking
(what you appear to call accumulation, I believe) from one PLL should be
no more than a dB or two. Unless you do that several times in a row, you
can probably live with the result.

Regards,

Paul Levin
Xyratex
___________________


Chris Cheng wrote:
> The jitter accumulation I am talking about is the jitter induced on the
> PLL on the receiver due to its supply or substrate. That applies to the
> PLL in the CDR that is needed to capture the incoming data, independent
> of whether the recovered clock is used to pass data down stream.
>
> ------------------------------------------------------------------------
> *From:* Paul Levin [mailto:levinpa@xxxxxxxxxxxxx]
> *Sent:* Tue 3/13/2007 8:51 PM
> *To:* Chris Cheng
> *Cc:* si-list@xxxxxxxxxxxxx
> *Subject:* Re: [SI-LIST] Jitter transfer vs. accumulation
>
> Dear Chris,
>
> In Fibre Channel at least, every time the signal arrives at a port, the
> serial signal gets reduced to logic. When the signal exits from this or
> any other port, the logic is re-serialized using some fresh, local clock
> source, most likely a crystal or SAW oscillator. (Any rate mismatch
> between input and output is absorbed by adding or deleting idle words
> between frames.) Thus, there is little opportunity for jitter accumulation.
>
> Regards,
>
> Paul Levin
> Xyratex
> _____________________
>
> Chris Cheng wrote:
>  > This stream of questions has been in my mind for the pass few years.
> And every time I went to DesignCon I ended up with more and more
> questions to myself rather than answers. So let me try to clear this up
> and let everyone hammer me back down to the ground :-D.
>  > Here it goes :
>  >
>  > It is a well know phenomenon that PLL suffers from jitter
> accumulation. i.e. Supply and substrate noise induced on the ultra high
> gain VCO resulting in jitter. Many ways have been invented to combat
> this including PLLVDD filters, on-chip regulators and most importantly,
> adjusting the PLL filter loop dynamics. It can be shown (and quite
> intuitively) that when you decrease the lock time and increase the
> tracking bandwidth, you allow the PLL to correct itself quicker with the
> induced jitter and thereby decreasing the peak to peak jitter.
>  >
>  > It is also a well known phenomenon that in the presence of input
> jitter, the loop dynamics need to be adjusted to minimize the
> propagation of the jitter. Worst there is a possibility of jitter
> peaking where the jitter may be amplified for a narrow band of
> frequency. It can also be shown (and again quite intuitively) that when
> you increase the lock time and decrease the tracking bandwidth, you
> decrease the jitter tracking of the PLL.
>  >
>  > So from the above, it is clear that the solutions to the two problems
> are contradicting each other. If you believe you have a problem with
> input jitter, you slow down your loop dynamics (or over-damped) in your
> PLL. If  you believe you have supply ripples or noisy substrate, you
> speed up your loop dynamics (well...at least make sure it is stable and
> not under-damped).
>  >
>  > To go deeper a little bit, what exactly are the input jitter we are
> talking about ? Well, let's use the convention jitter definitions, Tj,
> Dj,Rj,DDj,ISI,DCD,Pj etc etc. For most of the multi-gigabit systems I've
> seen, Dj seems to be the dominant component at the input in a system
> environment. Within Dj, I believe the DDj part is relatively high-speed.
> After all, your impulse response pre and post cursor dies down after a
> few UIs and your alternating rise/fall edge clock (DCD) happens in UI.
> The benefit of the PLL dynamics has little or no effect on such high
> speed jitters. Most (but not all) of PLL loop dynamics are at least 20x
> slower than the reference frequencies just to be stable. Any jitter
> happens within a few cycles of the sampling frequencies does not get the
> benefit of low jitter transfer at any stable loop filter settings. So
> now we have knock out the too big components of the input jitter, what's
> left ? My guess is the true Rj AND the jitter induced from the tra
> nsm
>  >  it circuit PLL (i.e. JITTER ACCUMULATION).
>  >
>  > So when we are trying to fight the jitter transfer by dropping the
> loop bandwidth, aren't we actually INCREASING the jitter accumulation at
> the transmitting end and we end up needing to cut the bandwidth
> downstream to minimize jitter transfer ? Does the solution we are
> implementing actually creates/worsen the problem ?
>  >
>  > To every designers we see our own devil, I sure would not like to
> impose my point of view on this issue on anyone who at least understand
> my points above. Whether you agree with me or not. However, seeing the
> latest FC or PCIe Gen II spec, it seems to be the group thinking has
> already been set to minimizing the jitter transfer is more important
> than the jitter accumulation. In fact, I am not even aware of any jitter
> accumulation spec in FC or PCIe (please correct me if I am wrong). The
> fact that Fc is set to something like 1667th of the bit rate means the
> PLL is way over damped.
>  >
>  > This seems countered to my own experience of characterizing PLL's
> where jitter accumulation almost always larger than true jitter
> transfer. I have to qualify that with the jitter definition above. Slow
> non-high speed input jitter transfer is what I am talking about. Dj's
> and specifically DDj input is big but not within the bandwidth of our
> discussion here.
>  >
>  > I know there are many smart brains that is responsible to come up
> with this 1/1667 bit rate Fc, so somewhere along my logic I must be
> wrong. Can someone point me to why jitter accumulation is less of a
> concern than transfer in these standard ?
>  >
>  > Chris
>  >
>  > ------------------------------------------------------------------
>  > To unsubscribe from si-list:
>  > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>  >
>  > or to administer your membership from a web page, go to:
>  > http://www.freelists.org/webpage/si-list
>  >
>  > For help:
>  > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>  >
>  >
>  > List technical documents are available at:
>  >                 http://www.si-list.net
>  >
>  > List archives are viewable at:   
>  >               http://www.freelists.org/archives/si-list
>  > or at our remote archives:
>  >               http://groups.yahoo.com/group/si-list/messages
>  > Old (prior to June 6, 2001) list archives are viewable at:
>  >               http://www.qsl.net/wb6tpu
>  > 
>  >
>  >
>  >
>



------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field


List technical documents are available at:
                http://www.si-list.net

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu