Maker Pro
Maker Pro

Phase frequency detector

M

Mike

Jan 1, 1970
0
First, the mode of failure is very strange. How can a simple pfd
work in different applications for years, then suddenly go bad?

It doesn't seem possible that it can be caused by one of the latches
resetting too quickly, leaving the other one still active. The set
and reset are one of the fastest circuits in D-flops, and the
minimum pulse widths are among the shortest listed in the datasheet.

Also, as Camenzind shows in Chapter 5, the first principle of linear
design is to rely on the close matching of parameters in
semiconductors. (Thanks for the url, Jim)

This means both flops should have similar reset times. When the
feedback path includes the prop delay of an added gate, the
resulting reset pulse width seems more than sufficient to guarantee
that both flops or latches will be reset.

Recall this circuit has been used for decades and millions of parts
have been shipped without problem. So why should it suddenly show up
in your product? If there were problems in resetting the latches, it
should have been there from the beginning.

One indication of the true problem might be that your code doesn't
seem to account for the prop delay and risetimes of the current
sources. In fact, it appears your code can produce no result other
than a straight line, regardless of how much deadband is atually
present in the circuit!

Perhaps this kind of analysis really needs to be done in SPICE,
which can do a better job handling the transients involved. An
example is shown in Fig. 6 of Johansson's "A Simple Precharged CMOS
Phase Frequency Detector", IEEE Journal of Solid-State Circuits,
Vol. 33, No. 2, February 1998. (Please Note - I do not necessarily
agree with anything else he says, but the SPICE simulations are
very nice:)

So I think your code mislead you into believing that deadband was
impossible in your circuit. Also, from your response, it appears you
do not have a dedicated tester to view the response of the pll to a
variable pulse. Without this simple test, you have no way to look at
the response of the latches and charge pumps and see how much margin
actually exists before deadband shows up.

Now here's my hypothesis. You had a small amount of deadband in your
circuit from the beginning, but with your typical use, it never
showed up. Perhaps the normal system jitter was sufficient to mask
the deadband.

However, the new customer required a faster lock time, which means
increased loop bandwidth. Perhaps the system noise was also better,
which gave reduced system jitter. Under the new conditions, the loop
developed a limit cycle oscillation, which can grow to be quite
large.

This may have misled you into believing there was a problem
resetting the latches. So you installed Jim's DualD-PFD circuit and
the problem went away:

Does this hypothesis sound reasonable and does it fit the available
information?



1. I've done the work in SPICE, and published the results previously in my
first post in this thread. I've also measured my PFDs in the lab, where my
measurement capability extended down to 100ps. No dead zone, ever.

2. Matching of nearby devices, especially small digital switching devices
and their load resistors, had a standard deviation on the order of around
1% at the time. Matching is good, but not perfect. That was all taken into
account when the gates were designed.

3. I did have a dedicated tester; it wouldn't have helped, but it wasn't
needed anyway. We could reproduce the error in the lab with no problem,
without a special tester. As far as measuring dead-zone is concerned, I've
measured a PFD in the lab down to 100ps error (the periods being compared
were 50ns), and measured no dead-zone.

4. It may not seem possible that a part could work for years then suddenly
fail, but it's happened to me on numerous occasions. In this case it was
because something in the customer's application changed, but not because
they changed the bandwidth.

5. The problem was there from the beginning. It was just outside the range
where the part was commonly used. When the commonly used range happened to
extend to the point where the problem could be seen, it was seen. As with
many IC problems, it was also process lot dependent, and didn't show up
until production began in earnest. Then, suddenly, every part in one lot
failed, and the next lot...

6. You've been assuming that the failure occurs at zero phase error, which
is incorrect: the phase error when the failure occurred was far from zero,
and is unrelated to dead-zone. The cause is well known to those of us who
worked on the problem, but I'm not giving away the answer here. I will
offer a clue: the flops are identical, but the reset path is not.

7. It's extremely obvious when a reset fails to occur, since it has the
effect of reversing the phase error, and the loop slips at least one cycle
before it recovers. The reason I thought Jim might have seen the same error
is that we didn't think of adding the SR flop until we had seen the
problem.

8. My program does ignore prop delay and rise time in the current sources.
Extending the solution I presented to include RC rise and fall times is not
terribly difficult (I've done that also), and it doesn't change the answer
- the charge transferred to the load is still linear down to very small
phase errors. Prop delays are irrelevant unless you can show that the
energy is going somewhere, and in the case of a diff pair, the only place
it has to go is to the output; it doesn't matter how long it takes to get
there. The intent of the code was to show that the charge pump diff pairs
do not need to fully switch, and the charge pump current does not need to
rise completely, to avoid a dead-zone or produce non-linearity.

9. Did you notice that Johansson's PFD has _increased_ gain around zero
phase error? I've seen that in some of the circuits I designed as well. In
Johansson's case it might be due to his pre-charged circuits, but it can
also result from certain charge pump mismatch effects (not device
mismatches). In that case, the effect is easy to prove mathematically.

10. Again, here are my SPICE results, on a real circuit. I've built this
one too, and since it forms the heart of an OC-48 synthesizer, a dead zone
would push the jitter out of spec very quickly. The jitter in this
synthesizer is a little over 1ps.

Time Charge
Diff. Output
(ps) (fC)
0.01 0.001
0.03 0.003
0.1 0.011
0.3 0.034
1 0.113
3 0.338
10 1.123
30 3.428
100 11.229
300 37.325

-- Mike --
 
J

Jim Thompson

Jan 1, 1970
0
[snip]
7. It's extremely obvious when a reset fails to occur, since it has the
effect of reversing the phase error, and the loop slips at least one cycle
before it recovers. The reason I thought Jim might have seen the same error
is that we didn't think of adding the SR flop until we had seen the
problem.
[snip]
-- Mike --

I *have * observed reset failures, thus my R-S approach.

Besides the obvious delay, it works because reset occurs when *both*
Q's are high and doesn't release until *both* QN's go high.

I haven't observed a reset failure with this method, but (disclaimer
:) it might be able to happen.

...Jim Thompson
 
M

Mike

Jan 1, 1970
0
[snip]
7. It's extremely obvious when a reset fails to occur, since it has the
effect of reversing the phase error, and the loop slips at least one cycle
before it recovers. The reason I thought Jim might have seen the same error
is that we didn't think of adding the SR flop until we had seen the
problem.
[snip]
-- Mike --

I *have * observed reset failures, thus my R-S approach.

Besides the obvious delay, it works because reset occurs when *both*
Q's are high and doesn't release until *both* QN's go high.

I haven't observed a reset failure with this method, but (disclaimer
:) it might be able to happen.

We haven't seen a reset failure with the R-S approach either, and we've
pushed it pretty hard to try to make it fail. We had to abandon it once,
when the speed was too high to include the R-S flop. It never failed, but
having been bitten once, it left me nervous for years.

-- Mike --
 
Top