Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Why is the offset of my PLL so large?

Status
Not open for further replies.

mssong

Junior Member level 2
Junior Member level 2
Joined
Jul 25, 2023
Messages
22
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
190
Why is the offset of my PLL so large?

The waveform of the TCXO and the divided waveform
UP and DN signals
UP current and DN current

I have attached the waveforms.

I have also attached the charge pump, vco type is LC. varacator cap is 200fF to 800fF.

스크린샷 2023-08-22 164714.png
스크린샷 2023-08-22 164753.png
 

Solution
If the DC analysis gives you a railed-loop initial condition
and the VCO has large regions where more or less VTUNE
makes no difference, you might end up stuck or needing
way more tran time than the loop time constant.

Might check for equal-delay-to-phase-det through the
REFCLK and FBCLK paths. Might have to compensate
the divider-chain delay. Although 30ns seems a long
timescale for anything GHZ-y, maybe the counter is a
dumb ripple with enough stages that it adds up.
Looks like phase detector says you are offset, and nothing is being
done about that.

Could be tuning range, could be that you flipped the logic and are
locking up, not locking-to. Could be that your loop filter is missing
and you just don't get proper tuning voltage for the VCO. And
generally you would have a divider stage between HF output and
the feedback clock, to get a frequency and phase match against
a low frequency high quality reference (these are not available
in GHz range, and granularity wants a low clock freq as the min
frequency increment I think?).

Maybe open the loop and see what VCO and @phaseDet freqs
you get from VTUNE pinned to either rail, and whether the UP/DN
result would then be trying to correct or worsen, as a start at debug.
 

Looks like phase detector says you are offset, and nothing is being
done about that.

Could be tuning range, could be that you flipped the logic and are
locking up, not locking-to. Could be that your loop filter is missing
and you just don't get proper tuning voltage for the VCO. And
generally you would have a divider stage between HF output and
the feedback clock, to get a frequency and phase match against
a low frequency high quality reference (these are not available
in GHz range, and granularity wants a low clock freq as the min
frequency increment I think?).

Maybe open the loop and see what VCO and @phaseDet freqs
you get from VTUNE pinned to either rail, and whether the UP/DN
result would then be trying to correct or worsen, as a start at debug.
I added a loop filter and locked the Vctrl to the desired frequency, but the waveform shows a large phase difference between the divided waveform and the TCXO's waveform (about 30ns).

The target frequency is 2.4ghz and we divided it by 240 to get 10MHz, so the period is 100ns.

I thought that the phase error of 30ns from 100ns is big, so I posted a question.

What could be the problem?

When I disconnected the up and down nodes from the charge pump and re-checked the current, I found that the mismatch was very small (about 0.05uA out of 50uA).

I also put an Inverter Chain on the reset node of the PFD to give it a delay (about 3ns) to avoid the dead zone issue.
 
Last edited:

A charge pump should have integral behaviour, strongly asymmetrical up/down pulse widths means integrator in saturation.
 

If the DC analysis gives you a railed-loop initial condition
and the VCO has large regions where more or less VTUNE
makes no difference, you might end up stuck or needing
way more tran time than the loop time constant.

Might check for equal-delay-to-phase-det through the
REFCLK and FBCLK paths. Might have to compensate
the divider-chain delay. Although 30ns seems a long
timescale for anything GHZ-y, maybe the counter is a
dumb ripple with enough stages that it adds up.
 
Solution
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top