PLL jitter and tracking filters

At 700 kHz, a CMOS 74HC4046 or 74HC9046 would do the job without much difficulty. If, by 'square wave' you mean your output is 50% duty cycle, it's maybe ALL you need. Not expensive, nor bulky, nor power-hungry, not at all.

But, what is the advantage of that? It's not clear what aspect of the input signal is significant, and what part is noise that can confuse the modulation. Jitter usually means edge-timing deviation from a perfect clock, and you could change the PLL loop filter to suppress cycle-to-cycle deviations if that were the only concern. If anything, a fast FPGA would sense a wide bandwidth of random noise and act on it, rather than suppressing out-of-band input.

Digital PLL is great if your input is digital (like, self-clocked asynchronous data), but not for a high-purity sinewave (which has timing data AT ALL POINTS IN THE WAVEFORM, not just at the 'logic threshold' point).

At the risk of stating the obvious: If the spectrum of the jitter falls within the bandwidth of the loop filter, it will pass through the PLL unattenuated. You should reduce the loop filter bandwidth.

Of course you may then run into tracking range problems...

Jeroen Belleman

The input frequency is the most significant, and what we are trying to extract and clean up. The "ideal" signal has very good short term stability, it drifts continuously over a long period of time (on the order of several seconds), but we haven't even gotten to real world signals yet. The test set up is simply a signal generator output that is attenuated, then amplified (to simulate a noisy signal), and then run through a sine->square converter. In our test set up we aren't even looking at tracking stability since the base frequency is constant and all noise induced is random. In principle the PLL should filter out the noise and reproduce (to some extent) our original signal.

The reason behind using and FPGA is that there is a potential remote sensing application and being able to quickly and easily reconfigure or adjust parameters without having physical access to the board is very desirable.

Andrey Shmakov University of California Berkeley Department of Physics

A 4046 and a DPOT? Horses for courses, and the amount of engineering time this seems to be taking up is pretty monumental for a university job!

Cheers

Phil Hobbs

Hi,

Is your input signal a sine wave, or is it already squared up?

One way to do this is to build a PLL using a DDS, clocked at 160 MHz maybe, as the local oscillator.

The input signal, if analog, would be mildly analog filtered and then digitized by the best ADC you can afford. Then the phase detector is essentially a lockin, integrating ADC samples multiplied by the MSB of the DDS. Close the loop to tune the DDS frequency. The result is of course time-quantized to the 160 MHz clock; if that's too much jitter, some number of DDS MSBs can be used to drive a DAC-lowpass-comparator to interpolate, just like any DDS synthesizer.

There's a little analog stuff outside the FPGA, but it's simple and you get a system that's easily tunable. A small FPGA could do all the work. This uses a Spartan3 to do eight DDSs, with all sorts of terrible modulations and stuff, clocked at 128 MHz.

What's the physics?

John

On Jun 16, 2:09 pm, crasic wrote: [... PLL ...]

Others are suggesting the CD4046 which is likely a better idea than the FPGA or that the jitter is withing the bandwidth.

If the jitter on the output is equal to but not identical to the jitter on the input, you may just be very unlucky with you numbers. Take a very careful look at how you made your filter. Basically, your filter and "VCO" need to do something like this:

if the input is before the output increase the frequency (long term) shift the vco phase earlier (short term) else decrease the frequency

You need to shift the phase because the VCO to phase detector represents an integrator and the filter is a second integrator. With two integrators inside the loop, the system will want to oscillate. The shifting of the phase of the VCO removes some of the phase shift and makes the loop stable.

You only need one phase shifting operation because the filter will settle just a little off the right value and the phase shifting will happen on every other cycle. This is equivelent to shifting in both directions by half the amount.

Doing the phase shift by one clock cycle works but forces you to have a "proportional gain" that works out to one clock cycle. You can make your phase shift by increasing the frequency for a while and then decreasing it again. In a phase accumulator style system this means that the phase number just needs to be increased by an extra amount some number of times after each phase comparison. In the programable divide by N style, it is a bit trickier but the N needs to be a little less.

PLLs of this sort tend to bobble back and forth by 2 clock cycles. You can improve on this if you put a backlash in the logic that drives the integration. So long as the phase shifting logic can keep the system in step, the integrator doesn't need to change at all. When more than some number (say 64) phase corrections land in the same direction, the integrator can be allowed to move.

So, omitting all obscure wording, all you need is output the input frequency averaged per X amount of time, right? The simplest way to do it in FPGA is just measure the period, calculate average and generate the output.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Hi,

I read your post over on the dsp group. But I find it difficult to help you due to what appears to be conflicting information.

Is the objective to track and clean-up a signal with undesirable short term stability, (jitter to be defined), but wanders 1-2 kHz over time?

Or is the objective to correct the wander of 1-2KHz signal that has good short term stability?

Over on the dsp group post you seemed to indicate that your NCO when run in the open loop static case had much worse pk-pk jitter that your ref source, (input test gen). Is this the case or not?

(A side note, typically in the comm/instrumentation world when speaking of jitter folks talk about this in terms of time or % of UI. In your case your speaking in terms of ave=92d freq measurements taken with a counter?)

regards, j

This is different from what you reported over at comp.dsp -- you corrected a problem?

Its loop gain is too high, leading to a too-high bandwidth. Find the design element that sets the loop gain and reduce it.

Without reading the papers involved, I'm suspicious of your methods. Digital PLLs are easy things to implement these days, where in the

If your FPGA design isn't easily separable into a phase comparator, a loop filter, an and NCO, then it's not a good design and working with it is going to be an ongoing PITA.

input signal -> phase compare --> loop filter --> counter value --> loadable down-counter --> output signal.

(If you need a "real" PLL at all -- think about Vladimir's response. If you need phase lock then you do need something that's going to be a PLL when all is said and done, though).

Or use a purely analog phase detector since the frequency is well-known with small deviations. I did that in a TACAN application almost half a century ago :-) Remarkable ability to pull a signal out of noise. ...Jim Thompson

There can be good reasons for using digital in circumstances like this, the OP's cited desire to be as flexible as possible is certainly one of them.

But when you're doing stuff like this, your digital circuit is ultimately just a simulation that's running in real time, pretending to be an analog circuit. Sometimes the best thing is to go for the real deal.

(All my training was for analog circuit design, with computers as a hobby on the side. Then the radio modem that I built for my Master's thesis absolutely DEMANDED crystal stability in the carrier reference along with wide frequency swings; I could either use up square feet of board space to do it all analog, or I could do it on the poor little slow 8-bit processor that had just been blinking lights on the front panel to implement the modem. The first five years of my professional career were a rear-guard action against doing all these nifty analog jobs in digital. Since then I've acquiesced: analog circuit design is for really little things, really fast things, or for accurately transitioning from the real world to digital and back).

Yep. Even MY recent chip designs are largely digital content, with analog peripheries :-) ...Jim Thompson

Where the challenge lies -- and where I see a lot of designs falling short -- is getting the care and feeding of the ADCs and DACs right, while not polluting your sensitive analog circuitry with digital noise.

It's easy to forget noise and bandwidth and DC offset and all that nasty analog stuff when you've just stumbled out of 10000 lines of code that define how the signals are processed once they're in the digital world.

Multiple rails. "Isolation walls" (deep diffusions). Bias distribution via current mirrors such that local references are relative to local rails, etc. ...Jim Thompson

Sorry to J and Tim for the spam, I accidentally hit reply to author instead of simply reply.

The input signal is essentially stable with some slow long term drift, You can think of it as a 700KHz signal with a 1KHz sweep width at 1hz. There is however plenty of fast noise that we want to eliminate. Right now I'm not even worried about the long term tracking, and simply feeding the PLL a noisy signal and seeing how well it filters. The signal used on the test bench is fixed with no sweep.

I omitted the details of the progress I made s>

Unfortunately I do need a phase lock. The circuit is acting as the control element in an oscillator loop, so it will be feeding an oscillator that is then feeding the pll. Having the two signals out of phase would not properly drive the oscillator.

The PLL from the papers is essentially how you described it. However the nco is set with an adjustable constant rather than constantly updated by the loop filter, this decreases the lock in range, but improves the tracking and supposedly the noise reduction. The loop filter then inhibits or adds fast clock pulses to the nco in order to lock onto the signal. I was originally using a more traditional pll, but since this design still had a variable center frequency and since we would know that frequency beforehand, the possibility of a cycle slip causing the a coarse frequency shift was not very appealing when compared to this alternative. The design however still has clearly seperated phase comparator, loop filter, and nco.

Fortunately the papers were very theoretical in that they didnt talk about specific hardware implementations at all. They gave a very general RTL diagram of the scheme and then s-parameters and mathematical analysis of individual loop elements, Fortunately they didn't require me to cut through any of the 70's specific hardware details that you mentioned

Andrey Shmakov University of California Berkeley Department of Physics

If you know in advance what the sweep pattern is, you can add that into the nco input, to feedforward-track the expected signal. Then the PLL can be a lot narrower-band and have less tracking error and/or less jitter.

Is your nco a DDS phase accumulator? That was difficult in the 70's, trivial in an FPGA now.

John

's

it

=A0If

I know in general what the sweep is (i.e. its slow and within 1Khz), but it is a natural process and therefore far from regular or predictable.

Since the oscillator I'm driving only requires a square wave to drive (with a 10% duty) my "NCO" is simply a counter and a flipflop. In an open loop it is simply dividing the base system clock to whatever center frequency I set, with a signal in the loop the loop filter inhibits or adds clock pulses into the counter, thus modulating the phase and (to a smaller extent) the frequency.

Andrey Shmakov University of California Berkeley Department of Physics

rt

e?

ur

at's

c,

h it

=A0If

PLL

Andrey,

Since your in the experimenting / discovery process:

And you know that the loop is stable and that your short term stability of your nco is better than your ref =85 why don=92t you just reduce the loop bandwidth by a factor of 10 and see what happens.

Of course this is an empirical approach, but you should see a improvement in your jitter.

The correct way to do this is to characterize the noise profile of the nco at the freq of operation which would then allow you to tailor the loop cross overs for your app.. But at least this will tell you if your on the right track and shouldn't be that difficult.

Regards j