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

[Paul Levin <levinpa@xxxxxxxxxxxxx>]

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:
>>> 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
>   
> 
> 
> 
------------------------------------------------------------------
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