http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.

txt

Q. Could you explain the cycle-skip phenomenon and its effect in PLL performance?
Did I have any method to reduce this phenomenon?

A. First, an explanation of what causes a cycle slip?

Let's start with a few examples?

Assume the PLL is just starting up and the feedback

clock (fbclk) is running slower than the reference
(ref). Also assume that the phase-frequency detector
(PFD) state is initially reset.

Ref arrives and sets the PFD state to "GoFaster". If

Ref is running more than 2X faster than fbclk, then a
2nd ref may arrive before the 1st fbclk arrives.
The PFD ignores the 2nd ref since the GoFaster state
is already set. This is an example of a cycle slip.

Another (better) example of a cycle slip:

Ref is running slightly faster (5%) than fbclk, and

the bandwidth of the PLL is much lower (100X) than the
ref frequency. After one ref cycle, the fbclk drifts
5% behind ref. After two cycles, fbclk is 10% behind.
After 20-30 ref cycles, the fbclk is about an entire
ref cycle behind. This is because the PLL bandwidth is
so low that it takes a long time to respond to the
frequency difference. As fbclk drifts farther and
farther behind ref, the PFD correctly detects that the
phase error is getting larger and larger.

When fbclk has drifted so much that it's a little more

than 1 ref cycle behind ref, the PFD now incorrectly
thinks that the phase error is only a small amount
instead of the previously-detected large phase error.
So, instead of trying to pull fbclk all the way back
to where it belongs (> 1 ref cycle), it pulls fbclk
back only to the nearest ref edge (<< 1 ref cycle). If
you count the number of ref and fbclk cycles during
this drift process and subsequent re-lock, you'll find
that there are more ref edges than fbclk edges. This
is defined as a cycle slip.

When the PLL is locked, you expect the number of

ref and fbclk cycles to be equal. When one is greater
than the other, then you are experiencing cycle slips.

If the PLL is initially locked, then cycle slips

occur for three reasons:

http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.txt (1 of 3) [2/14/2010 1:07:13 PM]

 http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.txt

1) the reference modulates frequency or phase faster

than the PLL can respond. e.g. Spread-spectrum
clocking is usually around 30kHz. If your PLL bandwidth is not
greater than 30kHz, then the PLL won't be able to keep
up with the reference modulation and cycle slips will
occur. You need to make the PLL bandwidth high enough
to keep up with the reference.

Also, the PLL transfer function exhibits peaking

around the natural frequency. If the peaking is too
large (low damping), then reference modulation at
the natural freuqency will lead to large phase error
and maybe even cycle slips.

2) The VCO is sensitive to power-supply noise.

Say the VCO frequency changes by 2.5% when VDD
changes. If it takes the PLL 100 fbclk cycles to
correct this frequency error, then the fbclk
will have slipped about two ref cycles by the time
the frequency error is corrected. So, you need to make
your VCO insensitive to VDD noise above the bandwidth
of the PLL. Note that high-frequency VDD noise does
not accumulate as much and so is not usually a cause
of cycle slips.

3) If the feedback divider cannot keep up with the

VCO, then you will occasionally miss fbclk edges.
This will make the PFD think that the VCO is going
too slow. This can cause the PLL to incorrectly
increse the VCO frequency, leading to a cycle slip.

One unexpected consequence of cycle slips is that

the PFD may temporarily respond in the wrong
direction. How?

Assume fbclk has drifted slightly less than one cycle

behind ref. Now, the rising edge of fbclk resets the
PFD state. If a ref edge arrives during the reset
process, it is ignored by the PFD. So, now the PFD
outputs are both low. Since fbclk is only slightly
slower than ref, the next fbclk is going to arrive
slightly BEFORE the next ref even though it is
actually running slightly slower. This is going to
cause the PFD to incorrectly think the PLL should SLOW
down instead of speed up. Fortunately, this incorrect
PFD decision persists for only one or two ref cycles.

The shorter the RESET delay in the PFD, the less

http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.txt (2 of 3) [2/14/2010 1:07:13 PM]

 http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.txt

likely that the PFD will output an incorrect decision.

However, we need the RESET delay to be long enough to
eliminate the DEAD-ZONE in the PFD. So, in general we
live with the occasional incorrect decision since it
typically occurs only during the lock process. The
lock time is slightly increased by this effect.

PLL designs have introduced self-resetting PFD's,

PFD's with dynamics gates, and other tricks
to minimize the RESET delay to the minimum necessary
to avoid a dead-zone.

http://www.delroy.com/PLL_dir/FAQ/faq_cycle_slip.txt (3 of 3) [2/14/2010 1:07:13 PM]