Dear Vinu, Don't you have the requirement backwards? The TxClk can use any PLL bandwidth it wishes since it is merely multiplying a crystal oscillator; the RxPLL is the one that is required to track frequency variations below Fbaud/1667 and ignore frequency variations above that figure. Regards, Paul Levin Xyratex ___________________ Vinu Arumugham wrote: > 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 > > > > ------------------------------------------------------------------ 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