[SI-LIST] Re: Jitter transfer vs. accumulation
- From: Vinu Arumugham <vinu@xxxxxxxxx>
- To: Chris Cheng <Chris.Cheng@xxxxxxxxxxxx>
- Date: Wed, 14 Mar 2007 11:02:34 -0700
Since the RX PLL VCO uses the board reference clock input, Fbaud/1667
does not apply to it. In such designs I think the RX PLL bandwidth can
be optimized without being constrained by Fbaud/1667.
Thanks,
Vinu
Chris Cheng wrote:
> But even in the CDR, there is a VCO that is sensitive to supply noise
> and your have to live with the broadband supply and substrate noise
> between Fbaud/1667 to Fbaud. The VCO can only correct by itself the
> injected noise below Fbaud/1667.
>
> ------------------------------------------------------------------------
> *From:* Vinu Arumugham [mailto:vinu@xxxxxxxxx]
> *Sent:* Wed 3/14/2007 9:58 AM
> *To:* Chris Cheng
> *Cc:* si-list@xxxxxxxxxxxxx
> *Subject:* Re: [SI-LIST] Jitter transfer vs. accumulation
>
> At least in the serdes designs we use, the PLL input clock is a board
> reference clock and is not derived from the data stream. In such
> designs, I think the CDR loop bandwidth (Fbaud/1667 spec.) is unrelated
> to the PLL bandwidth.
>
> Thanks,
> Vinu
>
> 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 transm
> > 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:
> >//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
> >
> >
> >
> >
>
------------------------------------------------------------------
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:
