[SI-LIST] Re: Jitter transfer vs. accumulation
- From: "Dhamija Naresh-B07930" <nareshd@xxxxxxxxxxxxx>
- To: <levinpa@xxxxxxxxxxxxx>, "Chris Cheng" <Chris.Cheng@xxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Wed, 14 Mar 2007 10:29:20 +0530
=20
As we are talking of jitter in PLL,I want to clear one doubt:
Looking at jitter specs. Of many Oscillators / Clk Generators, I found
that rms jitter nos. goes on decreasing as we increase the frequency.
What is the theory behind this behavior OR this is just Oscillator
specific.
Regaeds
Naresh
=20
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Paul Levin
Sent: Wednesday, March 14, 2007 10:21 AM
To: Chris Cheng
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: 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=20
> the PLL on the receiver due to its supply or substrate. That applies=20
> to the PLL in the CDR that is needed to capture the incoming data,=20
> independent of whether the recovered clock is used to pass data down
stream.
>=20
> ----------------------------------------------------------------------
> --
> *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
>=20
> Dear Chris,
>=20
> In Fibre Channel at least, every time the signal arrives at a port,=20
> the serial signal gets reduced to logic. When the signal exits from=20
> this or any other port, the logic is re-serialized using some fresh,=20
> local clock source, most likely a crystal or SAW oscillator. (Any rate
> mismatch between input and output is absorbed by adding or deleting=20
> idle words between frames.) Thus, there is little opportunity for
jitter accumulation.
>=20
> Regards,
>=20
> Paul Levin
> Xyratex
> _____________________
>=20
> Chris Cheng wrote:
> > This stream of questions has been in my mind for the pass few
years.=20
> And every time I went to DesignCon I ended up with more and more=20
> questions to myself rather than answers. So let me try to clear this=20
> 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=20
> accumulation. i.e. Supply and substrate noise induced on the ultra=20
> high gain VCO resulting in jitter. Many ways have been invented to=20
> combat this including PLLVDD filters, on-chip regulators and most=20
> importantly, adjusting the PLL filter loop dynamics. It can be shown=20
> (and quite
> intuitively) that when you decrease the lock time and increase the=20
> tracking bandwidth, you allow the PLL to correct itself quicker with=20
> the induced jitter and thereby decreasing the peak to peak jitter.
> >
> > It is also a well known phenomenon that in the presence of input=20
> jitter, the loop dynamics need to be adjusted to minimize the=20
> propagation of the jitter. Worst there is a possibility of jitter=20
> peaking where the jitter may be amplified for a narrow band of=20
> frequency. It can also be shown (and again quite intuitively) that=20
> when you increase the lock time and decrease the tracking bandwidth,=20
> you decrease the jitter tracking of the PLL.
> >
> > So from the above, it is clear that the solutions to the two=20
> problems are contradicting each other. If you believe you have a=20
> problem with input jitter, you slow down your loop dynamics (or=20
> over-damped) in your PLL. If you believe you have supply ripples or=20
> 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=20
> I've seen, Dj seems to be the dominant component at the input in a=20
> 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=20
> speed jitters. Most (but not all) of PLL loop dynamics are at least=20
> 20x slower than the reference frequencies just to be stable. Any=20
> jitter happens within a few cycles of the sampling frequencies does=20
> not get the benefit of low jitter transfer at any stable loop filter=20
> 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=20
> from the tra nsm > it circuit PLL (i.e. JITTER ACCUMULATION).
> >
> > So when we are trying to fight the jitter transfer by dropping the=20
> loop bandwidth, aren't we actually INCREASING the jitter accumulation=20
> at the transmitting end and we end up needing to cut the bandwidth=20
> downstream to minimize jitter transfer ? Does the solution we are=20
> implementing actually creates/worsen the problem ?
> >
> > To every designers we see our own devil, I sure would not like to=20
> impose my point of view on this issue on anyone who at least=20
> 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=20
> thinking has already been set to minimizing the jitter transfer is=20
> more important than the jitter accumulation. In fact, I am not even=20
> 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=20
> the bit rate means the PLL is way over damped.
> >
> > This seems countered to my own experience of characterizing PLL's=20
> where jitter accumulation almost always larger than true jitter=20
> transfer. I have to qualify that with the jitter definition above.=20
> Slow non-high speed input jitter transfer is what I am talking about.=20
> 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=20
> with this 1/1667 bit rate Fc, so somewhere along my logic I must be=20
> wrong. Can someone point me to why jitter accumulation is less of a=20
> concern than transfer in these standard ?
> >
> > Chris
> >
> > ------------------------------------------------------------------
> > To unsubscribe from si-list:
> > si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject=20
> field > > or to administer your membership from a web page, go to:
> > //www.freelists.org/webpage/si-list
> >
> > For help:
> > si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field > =20
> > > List technical documents are available at:
> > http://www.si-list.net
> >
> > List archives are viewable at: =20
> > //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
> >
> >
> >
> >
>=20
------------------------------------------------------------------
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:
//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: =20
//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
=20
------------------------------------------------------------------
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:
//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:
//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
Other related posts:
