The Designer's Guide Community Forum

The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Design >> Mixed-Signal Design >> PLL verification strategy (building blocks)
https://designers-guide.org/forum/YaBB.pl?num=1167304949

Message started by Visjnoe on Dec 28^th, 2006, 3:22am

Title: PLL verification strategy (building blocks)
Post by Visjnoe on Dec 28^th, 2006, 3:22am

Hello,

I would like to obtain some feedback on my current simulation set-up of the building blocks of an integer-N PLL (phase noise is out of the picture for now). Focus is on the correct simulation set-up and assessment of correct performance over PVT... Any comment/feedback is very welcome on missing items and/or mistakes in my simulation approach. I'm especially uncertain about the PFD/CP simulations...

1. PFD

Check waveforms in typical for certain phase offsets - transient analysis
-> is there a more systematic way to assess correct PFD operation over corners?
I was thinking about PFD gain (normally VDD/2*PI), but how do you determine if the simulated gain is OK or not?
Should it be exactly VDD/(2*PI)?
Concurrent on-time of UP/DOWN (over PVT) - transient analysis

2. CP

Noise: Put both UP/DOWN on and extract CP output noise (over PVT) - AC analysis
-> in the locked state, UP/DOWN are on for a certain fraction of the REF period (cf. on-time in PFD simulation).
Current mismatch: perform a simulation which checks the mismatch between the PMOS and NMOS current source -
DC + Monte-Carlo -> would a transient analysis be better?
Transfer curve: co-simulate PFD/CP for phase offsets between -2*PI and +2*PI and extract the average output current - transient analysis
-> How to assess this automatically over PVT, i.e. when does the transfer curve become good/bad? I know there should be no deadzone, but are there other metrics that are important? Can these be checked without inspecting transfer curves for all corners?
For know, all transfer curves are plotted on top of eachother and absence of the dead-zone is verified.
Leakage: I read something in papers about CP leakage but I don't quite grasp it: is it the leakage when the CP is in tri-state?
What would be a good simulation strategy and are there any formulae to assess the impact?

3. Divider

Functionality: does it divide by N (over PVT), at a lower/higher frequency than the nominal.

4. VCO

Start-up simulation (over PVT) - transient/RF analysis
Tuning range: sweep the control voltage and check the oscillation frequency (over PVT) - transient/RF analysis

5. LF

Noise: LF (resistor) noise density (over PVT) - AC analysis
Pole/zero location (over PVT) - AC analysis

Thanks in advance!
Visjnoe

Title: Re: PLL verification strategy (building blocks)
Post by ywguo on Dec 28^th, 2006, 10:24pm

Hi, Visjnoe,

Simulate PFD and CP together. Present REF and Feedback clock w/o phase error and verify the charge pump has not deadzone.

Why is the PFD gain is VDD/(2*PI)?

BG
Yawei

Title: Re: PLL verification strategy (building blocks)
Post by Visjnoe on Dec 29^th, 2006, 3:44am

Hello,

normally, the PFD has a linear output characteristic with slope VDD/(2*PI): this is because the average voltage output for zero phase offset equals zero and the average voltage output for 2*PI rad phase offset equals VDD (supply voltage of the PFD).

Thus, the slope of this curve (~ gain of the PFD) equals VDD/(2*PI)

On the PFD/CP verification: any comments on the other simulations? Concerning the deadzone: do you visually inspect all curves?

As I think about it, checking the first/second derivative of the transfer curve should also reveal the deadzone, namely there's a sharp discontinuity where it starts -> this could be checked automatically then.

Kind Regards

Visjnoe

Title: Re: PLL verification strategy (building blocks)
Post by emad on Jan 1^st, 2007, 12:22am

Checking the derivatives of the PFD/CP curves is a robust method to check dead zone.

Title: Re: PLL verification strategy (building blocks)
Post by ywguo on Jan 11^th, 2007, 11:25pm

Hi, Visjnoe,

For a PFD used in a charge-pump PLL, the gain of the PFD (K_p) has not a VDD term in its numerator. On William F. Egan's Frequency Synthesis by Phase Lock, 2nd ed., the author gives a very good description about K_p.

Quote:

The gain of the phase detector is equal to the charge-pump pulse current Ip divided by on cycle, since, if there wre a 1-cycle phase error, the average current woule equal Ip. This can be stated in terms of voltage by multiplying the current by resistance, usually part of the filter, and then adjusting the filter function to obtain the correct product. .... having K_p=I_p/cycle, ....

Obviously, the gain of the PFD is proportional to the charge pump pulse current, not VDD.

Thanks
Yawei

Title: Re: PLL verification strategy (building blocks)
Post by Visjnoe on Jan 12^th, 2007, 12:22am

Dear Yawei,

for the PFD/CP combination, I agree that the gain is given by what you state.

However, for a standalone three-state PFD:
1. the average voltage output at zero rad phase offset equals 0V.
2. the average voltage output for 2PI rad phase offset equals VDD (supply voltage of the PFD)

Assuming the PFD to be linear, the gain of the PFD is thus given by VDD/2PI (derivative of the transfer curve).

Kind Regards

Peter

Title: Re: PLL verification strategy (building blocks)
Post by loose-electron on Feb 1^st, 2007, 3:13pm

Some good points made above on deadbanding.

Also -
== Add impedances in the power and ground paths, noise injection on both power and ground rails, and run jitter analysis on that.
== Take a careful look at the charge injection of the CP steering transistors.
== Try and keep the loop filter inside the chip, if you come outside on this node, figure out the noise coupling ionto the bond pad, the variation between internal and external ground and add them into the simulation. After that, you will find a way to keep it inside.
== Local regulation of power (internal Vreg) is generally a "got to have" in noisy mixed signal environements.

Too many PLL's get analyzed to death and then you get bitten by all the noise and cross coupling of the applications environemnt.