[SI-LIST] Re: Jitter transfer vs. accumulation

  • From: "Chris Cheng" <Chris.Cheng@xxxxxxxxxxxx>
  • To: "Tang, George" <George.Tang@xxxxxxx>, <si-list@xxxxxxxxxxxxx>
  • Date: Thu, 15 Mar 2007 13:53:47 -0700

Once again, I don't think you get what I am saying.
Phase margin has NOTHING to do with the jitter accumulation test I am talking 
about. In fact the more phase margin you have (by over damping the loop) the 
more jitter you will accumulate due to power supply noise. This has nothing to 
do with zero phase margin and I sincerely hope you don't have a design that has 
zero degree phase margin.
The problem with the supply noise is as peripherals like DDR2/3 or CPU FSB is 
catching up with the Gb I/O's, their SSO harmonics are getting close to the 
band where the PLL vdd noise will severely impact the jitter accumulation. And 
there is not much you can filter if it happens inside the die.
-----Original Message-----
From: Tang, George [mailto:George.Tang@xxxxxxx]
Sent: Thursday, March 15, 2007 12:19 PM
To: Chris Cheng; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation



Chris, 

 

I gave you the point that if you do a frequency sweep on the power noise of a 
PLL (not a VCO), you can induce a growing resonance of jitter eventually to the 
point that the PLL blows up (loses lock).  You can call this "jitter 
accumulation" if you wish.  This happens simply because the power noise 
modulates the VCO output.  The phase comparator at the PLL input that is trying 
to keep track and correct the phase difference between the VCO output and the 
RefClk input can no longer correct the phase difference.  This is exactly the 
same as if you do a frequency sweep at the RefClk input while the PLL power is 
kept noise free.  The phase comparator at a certain frequency will no longer be 
able to track and correct the phase difference between the VCO output and the 
RefClk input.  You need to analyze the phase margin and gain margin of the 
feedback control system to determine at what frequency the system will blow up 
- when the phase margin becomes zero.  This is just a simple control system 
analysis, not the black magic arithmetic you described below.  You are also 
wrong about the DLL not blowing up.  The DLL also needs to meet the phase 
margin requirement.  With enough power noise at the right frequency, it will 
blow up, too.  You can reduce the gain of the circuit to improve margin, but 
that decreases the PLL performance.  The best way is to reduce the noise 
disturbance frequency, or lower the RefClk jitter frequency - different 
approaches, same effect.  Like I said in the previous email, you have found a 
peculiar way to break the PLL, but the PLL is not designed to handle frequency 
sweeps.  I fail to see the significance of the stories that you describe.  

 

 

George 

 

Note: Effective October 14, 2006, My LSI Logic Email address will change to:  
george.tang@xxxxxxx

Please update address books and email lists accordingly.


  _____  


From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx] 
Sent: Wednesday, March 14, 2007 10:53 PM
To: Tang, George; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation

 

If I correct my statement here : "You will see the AC noise induced on your 
PLL" to this :

"You will see the AC noise induced JITTER on your PLL" , will that make my 
statement better ?
I don't know how much more clear I have to explain my view below that I am a 
true believer of phase noise accumulation due to power supply or substrate 
induced noise. Especially between the loop passband to the reference frequency 
and I have explain why below also. You can dig up many papers to study why this 
happen. Part of the originally attraction of DLL verse PLL is because it 
doesn't have the 1/s integration pole on the VCO, it is unconditional stable 
and therefore you can shift your loop bandwidth to as close to the reference 
frequency as you want, thereby decreasing the jitter accumulation. But if you 
drop it down to 1/1667 of the reference frequency, you make it even worst than 
what a PLL can do with proper loop dynamic.

As to the comment about bicycle helmet running into a car, let's do the math 
here. Start off with how small a fraction of the cycle of jitter you can 
tolerate in radians. Divide by the VCO or VCDL gain in radians per volt (which 
should be a big number). That's how much noise you can live with in your VCO or 
VCDL per cycle. Now divide by how many cycles the jitter can accumulate until 
the loop can correct itself (i.e. the ratio between the reference frequency and 
the loop bandwidth, to first order), and you will realize how little noise your 
VCO/VCDL can tolerate before your jitter budget is out of spec at the right 
frequency. And I can assure you if you hit it with the right frequency, you can 
knock your PLL or your DLL jitter budget out with a surprisingly small amount 
of noise. Don't take my word, do the experiment yourself on any PLL/DLL you get 
your hand on. 

 


  _____  


From: Tang, George [mailto:George.Tang@xxxxxxx]
Sent: Wed 3/14/2007 8:13 PM
To: Chris Cheng; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation

By now, I believe you agree that VCO jitter does not accumulate.  If I
modulate the VCO voltage with a 50mV low impedance power source at a
fixed frequency, the power noise will be fixed at 50mV (again, low
impedance), therefore, the output jitter will be fixed at a certain
amount.  No accumulation there.  For the PLL, that is a different story.
There is the refclk input the PLL tries to lock to and there is the
power noise disturbance.  Certainly, if you inject enough voltage noise
into power and do a frequency sweep, a wide bandwidth PLL will blow up
(loses lock) at some point.  But what is the point of this?  Power
supply noises should be kept low, and they are usually switching at a
fixed frequency, not a sweeping frequency.  If you take a bicycle helmet
and run it over with a car, you tell the helmet maker that it broke.
The helmet maker would tell you that the helmet is not designed to
survive a car crash.  You simply found one way to break it.  I'm sure
there are a million different ways that will break it also. 

Thanks,

George


Note: Effective October 14, 2006, My LSI Logic Email address will change
to: george.tang@xxxxxxx

Please update address books and email lists accordingly.


-----Original Message-----
From: Chris Cheng [ mailto:Chris.Cheng@xxxxxxxxxxxx]
Sent: Wednesday, March 14, 2007 7:21 PM
To: Tang, George; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation

How does the jitter get accumulated ?
Let's do this experiment. AC isolate your PLLVDD, inject a fixed
amplitude but varying frequency AC noise into your PLLVDD. In
particular, sweep it between the pass band of the loop filter and the
reference clock frequency. You will see the AC noise induced on your PLL
supply get accumulated (bigger and bigger) as you sweep your noise
frequency from the refclk frequency down to your loop filter pass band
and graduately decrease as the phase detector finally be able to correct
the phase error induced by the AC VDD noise.
The simple explanation is as AC power noise get injected into your high
gain VCO/VCDL, the phase error introduced is too fast (because the
modulation is beyond the pass band of the loop filter) to be instantly
corrected and required multiple cycles to accumulate enough charge in
the loop filter to pull back to the reference frequency. Hence jitter
accumulation.
BTW, I believe there are many papers descripting the above issue. And
believe it or not, I tested your company's first ever PLL design and
wrote the first PLL filter app note for it while I was in another
computer company. The details are in there, I hope you can dig it up
again from somewhere :-D.

-----Original Message-----
From: Tang, George [ mailto:George.Tang@xxxxxxx]
Sent: Wednesday, March 14, 2007 6:59 PM
To: Chris Cheng; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation


Now that you specify VCO, so let's talk about that.  A VCO is an
oscillating circuit in which the oscillation frequency is controlled by
the voltage.  Now if you have power noise (say sinusoidal), you are
modulating the VCO so you have sinusoidal jitter at the output.  Where
does the "jitter accumulation" come from?  I do not understand the term
you use. 

I believe you also did not understand Vinu and Paul's comments about
capturing the received data signals into logic levels and re-transmit
with a separate reference clk driven PLL.  The PLL has only one input --
the ref_clk.  The PLL may have multiple phase output which can be used
to drive the phase interpolator input.  But there is still no jitter
accumulation there.  If you are talking about the recovered clock, yes,
the PLL jitter along with the CDR jitter plus the transmitter jitter
will add.  But some of this jitter will be filtered out by the next
stage PLL. 



George


Note: Effective October 14, 2006, My LSI Logic Email address will change
to: george.tang@xxxxxxx

Please update address books and email lists accordingly.


-----Original Message-----
From: Chris Cheng [ mailto:Chris.Cheng@xxxxxxxxxxxx]
Sent: Wednesday, March 14, 2007 6:14 PM
To: Tang, George; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation

I am not sure about that.
I have to apologize I confuse everyone by using the term PLL and you
will automatically interpret it as the PLL that is related to the Refclk
generation in the receiving side. But I think the term VCO is a better
discription because it encompass both PLL and DLL. And VCO is where the
supply noise will be converted to phase noise (jitter accumulation).
The real question I have in the receiving area is the VCO in the CDR of
the receiving chip.
As Vinu and Paul pointed out, if there is no Xtal input for the Rx and
the clock is completely recovered from the data, we probably will agree
that PLL dynamics hold there.
However, even if we are talking about, and I think that's what Vinu was
refering to, a dual loop CDR with a seperate Rx clock PLL and use phase
interpolators for some kind of bang bang slave loop, you still need a
master phase generator using a DLL somewhere that will generate those
multi-phases. And that DLL will have a VCO and it will suffer from VDD
or substrate induced phase noise. This is independent of whether the
original refclk PLL dynamics. If you tell me that the multi-phase
generating DLL does not need to be held at 1/1667 bandwidth, all my
confusion is cleared.

-----Original Message-----
From: Tang, George [ mailto:George.Tang@xxxxxxx]
Sent: Wednesday, March 14, 2007 5:46 PM
To: Chris Cheng; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Jitter transfer vs. accumulation


Chris,

You sound very confused.  A receiver core has 2 types of inputs --
reference clock input and RX data channel input.  You have these 2 types
of inputs mixed up completely.  Once you understand that they are
separate, most of your questions clear up automatically. 

Thanks,

George


Note: Effective October 14, 2006, My LSI Logic Email address will change
to: george.tang@xxxxxxx

Please update address books and email lists accordingly.


-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [ mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Tuesday, March 13, 2007 6:47 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Jitter transfer vs. accumulation

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
  

Other related posts: