Timing stability of MCU PLLs

[WatchfulEye]

I've reactivated some personal MCU projects after a hiatus of about 15 years - and these days, things are all high speed and running off internal PLLs, when I was used to clocking MCUs of crystal oscillators.

One of my first projects was just a very simple interval timer. I used a microchip ARM M4 (SAMD51) MCU clocked to 120 MHz from the interal PLL which was driven from an external crystal. However, I've found the event capture/timestamp peripheral to record much more timing jitter than I was expecting.

Testing with a 100 Hz signal from a signal generator, revealed a p-p period jitter of over 1000 clock cycles (about 8 microseconds) which I found surprising. So, I tried it with a GPS receiver PPS output, which was only marginally better (about 600 clock cycle jitter on the PPS pulse edge).

I'm curious if there is some sort of user error here, as I was expecting better performance. One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

[ataradov]

How exactly do you capture the period?

This is is definitely out of any reasonable bounds. So something is not right.

Reference source should not matter that much. PLL works better with a reference around 2 MHz, but using 32 kHz as a reference is normal.

Note that there is an errata about reference < 400 kHz. You may be running into it. Make sure that OSCCTRL.DPLLCTRLB.LBYPASS = 1

[WatchfulEye]

The period is captured with one of the timer/counter (TC) peripherals. It's operated in input capture mode with timestamping. An ISR is used to retrieve the captured timestamps.    The TC is operated in 32 bit mode with an overflow ISR to keep track of the high word. The TC is clocked off the 120 MHz clock which is also used by the MCU core.

Thanks for info on the erratum. However, I've checked and LBYPASS is 1.

I've done some further testing. I used one of the TCC peripherals to generate a PWM signal, and then routed that signal into the input capture pin of the TC. When the PWM source is clocked off the 120 MHZ core clock via a prescaler, I get +/-1 cycle measured jitter, which is what I was hoping for. When the PWM is clocked off the 32.8 kHz XO then I get hundreds of cycles of jitter, suggesting that it is the 120 MHz clock that is unstable.

I've been through the PLL section of the datasheet, and run a program to brute force through the various filter options. I seem to have improved things a bit, by turning off delta-sigma modulation and increasing the loop filter bandwidth to maximum. With the best settings, jitter on the 100 Hz signal is down to about 600 cycles. The following is a histogram (cycles per 10 ms period) of a short run of 100 Hz signal with the best PLL settings, but even so, the jitter is still significant.



I think the next step will be to try and use an external oscillator, and use one of the GPIOs as an input to one of the MCU's clock generators.

[ataradov]

Also check coarse and fine step settings. Often frameworks use  large values, which speeds up lock time, but may not be great for jitter.

And another, even more critical thing is to check that you are not using buck converter for the VDDCORE. There is even worse errata about that - 2.19.1 "Buck Converter Mode".

Table 54-53. "Fractional Digital Phase Lock Loop Characteristics" says that typical period jitter for f_IN = 32 kHz, f_OUT = 200 MHz is 3.4 % (max is 4.9%).

So it looks like you are below that, if I did not get confused by math.

[Foxxz]

If you are using the Arduino framework for precision timing you should be aware that there are probably some timer interrupts/overflows happening that aren't explicitly shown in your sketch. There are instructions for disabling them that may impact some of the built in functions.

[ataradov]

If you are using the Arduino framework for precision timing you should be aware that there are probably some timer interrupts/overflows

He is using TCC's hardware capture function. It is not affected by any interrupts or software delays (within reason). At least that's the way I read the description of the method.

[PCB.Wiz]

One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

Some (most?)  MCUs that lock using the 32Khz oscillator, do not use an analog PLL, but instead use a trim-lock DFLL - ie they check the on chip RC oscillator and snap that to the nearest trim point to correct.
USB MCUs which lock to the 1ms USB frame use this digital locking design too.
The long average is crystal locked, but the jitter is of RC oscillator levels.
If you need lowest jitter, can you find a HF crystal board to try ?

[ataradov]

There are both DFLL for 48 MHz output (used for USB) and a true DPLL, which is tested in this case.

[harerod]

Sidenote: Sometimes a slight jitter is desirable to lower the radiated emissions at MCU clock frequency by spreading it a bit over the spectrum. For example, the STM32F407 has this feature. The same trick may be used by other switching elements, e.g. DCDC-converters. EMC compliance tests account for this by defining narrow band and wider band absolute maximum levels.

[David Hess]

I would configure a timer/capture unit for a square wave output and measure the jitter with an oscilloscope to find out if the jitter is inherent to the microcontroller's internal clock.  One trick might be to trigger the oscilloscope on the 32 kHz source to make this measurement.

[ataradov]

This measurement is quite challenging. The minimum output frequency of the PLL is 96 MHz, and the pad bandwidth is way lower. So you get pretty clean sine wave on the output if you put it directly on the pin. And dividing the clock cleans it up.

It is worth trying, but I would not expect great results.

[David Hess]

This measurement is quite challenging. The minimum output frequency of the PLL is 96 MHz, and the pad bandwidth is way lower. So you get pretty clean sine wave on the output if you put it directly on the pin. And dividing the clock cleans it up.

It is worth trying, but I would not expect great results.

Can you make the direct signal available on a pad?  Often ARM microcontrollers clock peripherals at a much lower frequency than the core.  Timer/counter measurements are not affected by this but core manipulation of the I/O ports sure is.

Since the jitter is currently being measured using a 100 Hz or 1 Hz signal, dividing it down before measuring the square wave output would be appropriate anyway.

[ataradov]

Can you make the direct signal available on a pad?

Yes, but it still will be 96 MHz going over 60 MHz pad at best. It will be a pure sine wave with slightly reduced amplitude. It is still probably good enough to measure the jitter.

Let me just grab a board and see what I get.

[PCB.Wiz]

I'm curious if there is some sort of user error here, as I was expecting better performance. One thing I'm suspecting is my choice of dev board (adafruit arduino clone - metro m4 express) which is equipped with an external 32.8 kHz crystal, rather than anything faster (and inconveniently the MCU's MHZ range XO pins are not exposed) - if this is the case, is the PLL frequency multiple of 3665 a bit too high to give good stability?

Yes, it will have worse jitter at lower PFD values.
If the PLL is an analog PLL, (as mentioned above) at 32kHz it only samples phase every 30us, which is a lot of hold time and low update bandwidth - all that means more jitter on the VCO.

[ataradov]

I used 12 MHz oscillator divided by 6 as a reference and configured PLL to run at 120 MHz. I have no way to observe 120 MHz, so I divided it by 12 before putting it out in a pin.  I see 20-40 ns of jitter compared to the reference clock. And occasionally it is much worse. But you can clearly see that it is locked with this configuration. With 32 kHz reference - not so much.

From what I can see it does work better with higher reference clock, and higher output frequency.

It is very hard to observe measure this with basic equipment I have here.

Here are captures over a minute or so of 2 MHz reference and 120 MHz divided by 60. First one is  right at the trigger, and the second one with a trigger 1 ms in the past. So it is locked and maintains the lock.

And one more thing to keep in mind - with 32 kHz reference and 120 MHz output, you will likely have fractional multiplier. And that can also contribute to jitter.

[ataradov]

If you do the same thing for 32 kHz reference, and divide 120 MHz by 3662, then the output is also perfectly locked and the jitter of that divided signal is 5 us.

[WatchfulEye]

Thanks for all the comments, especially to Ataradov for doing the experiment I wanted to do, but I don't have any spare oscillators with suitable output.

However, I was quite interested in this, so did a similar experiment - exporting the 32 kHz ref clock to a pin and then connecting it to the input capture pin of the timer. I then captured the times of the clock rising edge under a variety of PLL settings, and computed the frequency deviation over various averaging times.



The above image shows the fractional frequency deviation of the timer frequency (y-axis) as a function of averaging time in comparison with the 32 kHz PLL ref clock.

The main finding is that there is very little difference - other than slightly more time jitter with the lower frequencies, and a further slight penalty when using a fractional multiplier. There is a big difference from setting the wrong PLL loop filter (the discrepant example used a 46 kHz loop bandwidth, compared to 185 kHz for the others).

As a bouns, I was able to verify that the interval timer code works and doesn't lose events even logging 32k events per second. 

[WatchfulEye]

I thought I'd post an update, as I managed to obtain and get a 10 MHz oscillator working on my board. The pins necessary for crystal operation are not exposed, but the XIN pin can be used for a CMOS output oscillator, and this is exposed via the ICSP header. As I was feeling lucky, I bought an unknown oscillator off amazon - which turned out be sine output. After some trial and error, I found that this did in fact work with the MCU if AC coupled to the XIN pin, and setting XOSCCTRLn.XTALEN = 1 (presumably setting XTALEN enables a bias network internal to the MCU).

The experiment entailed inputting the 10 MHz clock, and routing the clock to a) a PLL and setting various ref frequency dividers, and multipliers to yield 200 MHz which was used to clock the input capture TC peripheral, and b) a /128 divider and routing the 78 kHz pulses to the input capture pin, and logging the timestamps, which could be used for analysis. The resulting analysis should represent the frequency stability taking into account the timer resolution and the PLL performance only.



As can be clearly seen, the higher the ref frequency, the better the PLL performance. I wasn't expecting 5 MHz to work, as it is significantly out of spec for the ref frequency, but it does work and gives better performance than 2.5 MHz. I don't know why the 1.25 MHz curve has a different shape to the others. I repeated this measurement several times, thinking it was an undetected data corruption issue (e.g. lost samples), but it is a consistent finding.

For context, the performance arising from the 5 MHz line represents a standard deviation of the timestamps of approx 0.8 clock cycles (4 ns). For the 39 kHz ref requency, the timestamp precision is about 2 orders of magnitude worse, unless measuring very short intervals (< 1 ms).

[ataradov]

PLL is sensitive to temperature. 5 MHz would likely not work at higher temperatures.

[PCB.Wiz]

PLL is sensitive to temperature. 5 MHz would likely not work at higher temperatures.

I think that is the PFD frequency, not the VCO frequency ?

[ataradov]

Yes, but it has its limits, and the maximum supported reference frequency is 3.2 MHz. This PLL is known to have locking issues at extreme temperatures with low reference frequency (< 1 MHz). I have not tried it with higher frequency, but I assume similar thing will happen. I have no idea what happens on a low level.

[peter-h]

Why would the PLL be temperature sensitive?

I would expect the on-chip clock multiplier to be a DPLL.

[ataradov]

Because it is a physical device implemented in silicon. Physical things have limitations.

[peter-h]

Is it a DPLL, or an analog PLL (a VCO, etc) implemented in silicon? A VCO has to be analog, at least.

[ataradov]

It is a digital PLL. There is still a VCO, of course, how else would it generate high frequency. The VCO is digitally controlled by a phase detector, which is also digital.

[WatchfulEye]

I thought I would post an update. I seemed to have got a little bit obsessed with timing, so tried to improve further on capturing the timing of events.

I seem to recall seeing a design for a GPSDO which used an ADC and filter to serve as a time digital converter, so I had a go at doing the same. I used one of the MCU's asynchronous programmable logic blocks to implement an edge triggered SR latch, which could be coupled to an RCD peak detector/filter and routed to an ADC.

Given the apparent crudity of the solution I have been quite impressed by the performance.

Here is a phase difference plot comparing the MCU's 10 MHz LO clock against a GPS PPS signal. Blue, shows phase as measured by a 200 MHz timer/counter clocked from the MCU's PLL (10 Mhz / 4 * 80). Orange shows phase as measured by a 10 MHz TC clocked direct from the oscillator, with analog TDC. The scales are the same, apart from absolute value which I am not interested in here. As these were two separate acquisitions, both have been frequency corrected, in order to show the detail of the phase measurements.



As can clearly be shown, the 200 MHz TC based trace (blue) is dominated by phase noise in the PLL. The hybrid system (orange) clearly shows the 64 MHz quantisation of the GPS PPS signal and frequency offset of the GPS receiver's clock.

Abbreviated schematic of hybrid TDC (internal calibration connections/logic omitted)

[David Hess]

Old DSOs work something like that.  They measure the time difference between the trigger and sample clock to properly align the samples in the acquisition record.  This is done by using the trigger to start charging a capacitor and the sample clock to stop charging it.  Then the charge in the capacitor is measured, which could be done by an ADC but more commonly a timer/counter is used.  A resolution of 10s of picoseconds is relatively easy but better than this is possible with careful attention to design.

In order to get past the problem of having such a narrow pulse control charging of the capacitor, two digital signals are used with one starting charging and the other stopping it.  Multiplexers on the digital side apply a series of test pulses for calibration.

This page is very informative about the various time to digital schemes.

[WatchfulEye]

Many thanks for that - plenty of good food for thought.

My crude attempts haven't managed to get much better than about 800 ps precision, but nevertheless I did suceed in my little educational project which was to improve on my "my first interval counter" project. 

[David Hess]

Many thanks for that - plenty of good food for thought.

My crude attempts haven't managed to get much better than about 800 ps precision, but nevertheless I did succeed in my little educational project which was to improve on my "my first interval counter" project.

Something can be learned from the last DSOs that Tektronix made with full documentation, like the 468/2221/2230/2232, and 2430/2432/2440 which describe their time to digital circuits in detail.

[Doctorandus_P]

More measurements of PLL (in) stability in microcontrollers:
https://www.jaybee.cz/software/stm32-hse-oscillator-stability-problem/
https://blog.dan.drown.org/gps-module-measurements/
I find the saw-tooth like deviations with a period of over 30s quite strange.

And a bit of searching finds more links:
https://html.duckduckgo.com/html?q=microcontroller+PLL+loop+stability

In the end the uC manufacturers do not seem to care. As long as the general PLL does it's job to generate a clock that the uC can run on they're apparently content.

[PCB.Wiz]

More measurements of PLL (in) stability in microcontrollers:...

Has anyone explained the mechanism here ?
Those are very long period error sawtooths, and they seem strangely imprecise too, yet very 'sawtoothy' at the same time.
What on the MCU has those periods ?
Is it an artifact from a default-watchdog ?

[WatchfulEye]

I just thought I'd post an update.

I'd spent longer than sensible trying to copy some of Tek's designs, and I also tried some less linear designs and used some software linearity correction (By sampling an uncorrelated clock, the distribution of phase measurment should be uniform. By building a CDF, inverting it and fitting a polynomial, a linearity correction can be derived). I was never able to get much better than a SD of about 400 ps.

I then tried a formal time-digital-converter (TI TDC7200) and the performance wasn't any different. After a lot of experimentation, I found that the performance was drastically better if I used external logic, rather than the MCU's internal programmable logic block.

The final set of experiments showed that I could achieve the TDC7200's rated precision of an SD of about 60 ps, with external logic and a clean, externally buffered clock. However, using any logic clocked by the MCU's internal clock generator, or clocking the TDC off the MCU's clock output, immediately added about 300-400 ps of rms jitter to the phase measurements. My conclusion is that the internal clock distribution networks in the MCU themselves add about 300-400 ps rms of jitter

[PCB.Wiz]

I just thought I'd post an update.

I'd spent longer than sensible trying to copy some of Tek's designs, and I also tried some less linear designs and used some software linearity correction (By sampling an uncorrelated clock, the distribution of phase measurment should be uniform. By building a CDF, inverting it and fitting a polynomial, a linearity correction can be derived). I was never able to get much better than a SD of about 400 ps.

I then tried a formal time-digital-converter (TI TDC7200) and the performance wasn't any different. After a lot of experimentation, I found that the performance was drastically better if I used external logic, rather than the MCU's internal programmable logic block.

The final set of experiments showed that I could achieve the TDC7200's rated precision of an SD of about 60 ps, with external logic and a clean, externally buffered clock. However, using any logic clocked by the MCU's internal clock generator, or clocking the TDC off the MCU's clock output, immediately added about 300-400 ps of rms jitter to the phase measurements. My conclusion is that the internal clock distribution networks in the MCU themselves add about 300-400 ps rms of jitter

Nice tests.
What MCU did you test with, with what clock setups ?
I assume "any logic clocked by the MCU's internal clock generator" includes no PLL operation (so PLL jitter is not in the test here) ?

I guess that makes sense, as MCUs are inherently noisy environments, with GND and VCC bounce that varies based on what logic is switching, and that varies by opcode and memory access and even address values.
Maybe the simple built XTAL oscillators are a bit worse there, than external CLOCK sources, as even the sine threshold will have that small but finite noise imposed on it ?

Did you try External CMOS Clock -> MCU > ClockOutput with MCU in IDLE & then NCU running memory patterns ?   The IDLE case should be close to ideal / minimal added jitter ?

I have used IDLE carefully in the past to eliminate opcode jitter,  but it should also help reduce clock jitters, as much less is happening internally.
Maybe one solution is to choose a smallest MCU with CLU and timers good enough for the tasks, and treat is more like smart logic than a MCU, so it slave to another chip as the main processor.

[David Hess]

I'd spent longer than sensible trying to copy some of Tek's designs, and I also tried some less linear designs and used some software linearity correction (By sampling an uncorrelated clock, the distribution of phase measurment should be uniform. By building a CDF, inverting it and fitting a polynomial, a linearity correction can be derived). I was never able to get much better than a SD of about 400 ps.

Measuring the distribution with an uncorrelated input is suppose to work really well to find the linearity correction.  Tektronix may have done that during infrequent system calibration, but calibration of zero and gain use reference timing waveforms whenever the sweep speed is changed.

I then tried a formal time-digital-converter (TI TDC7200) and the performance wasn't any different. After a lot of experimentation, I found that the performance was drastically better if I used external logic, rather than the MCU's internal programmable logic block.

The final set of experiments showed that I could achieve the TDC7200's rated precision of an SD of about 60 ps, with external logic and a clean, externally buffered clock. However, using any logic clocked by the MCU's internal clock generator, or clocking the TDC off the MCU's clock output, immediately added about 300-400 ps of rms jitter to the phase measurements. My conclusion is that the internal clock distribution networks in the MCU themselves add about 300-400 ps rms of jitter

I am not quite surprised.  I have seen that level of pattern dependent jitter from TTL and CMOS logic when other stages modulated the power supply voltage, and I have heard reports of similar levels from ASICs and programmable logic under adverse conditions.  The two solutions I have seen with discrete logic are to either closely regulate the supply voltage, or use differential logic like ECL where the reference can be separate from the ground or supply voltage.

[WatchfulEye]

Nice tests.
What MCU did you test with, with what clock setups ?
I assume "any logic clocked by the MCU's internal clock generator" includes no PLL operation (so PLL jitter is not in the test here) ?

I guess that makes sense, as MCUs are inherently noisy environments, with GND and VCC bounce that varies based on what logic is switching, and that varies by opcode and memory access and even address values.
Maybe the simple built XTAL oscillators are a bit worse there, than external CLOCK sources, as even the sine threshold will have that small but finite noise imposed on it ?

Did you try External CMOS Clock -> MCU > ClockOutput with MCU in IDLE & then NCU running memory patterns ?   The IDLE case should be close to ideal / minimal added jitter ?

Apologies for delay.

I tested with a microchip ATSAMD51J19A (Cortex M4 +) on an adafruit arduino clone (Metro M4 express) board (https://learn.adafruit.com/adafruit-metro-m4-express-featuring-atsamd51/downloads)

The clock setup is an external CMOS clock generated by a separately powered CMOS square-wave OCXO, level shifted with a 74LVC1G17 schmitt trigger, then delivered to the XOSC0IN pin, and from there routed to a 1:1 generic clock generator, and from there to the timer/counter and programmable logic peripherals.  There is no PLL in the clock path.

Using a minimally loaded FPGA powered from its own LDO to generate timing signals gives very good results - When loaded with only a flip-flop chain, it is indistinguishable as a stop trigger generator from discrete flip-flops, and when used to divide the main clock to provide a coherent PPS, the measured jitter is equal to the TDC7200's specified noise floor.

However, I have indirectly done a CPU load experiment using a PPS signal from a GPS unit. In the attached figure, I have plotted the time between consecutive PPS pulses as measured by my interval counter while the receiver is tracking either 1 constellation or 2. If you ignore the gross quantization error, the increased jitter when running in 2 constellation mode (red) is clearly visible, including some peculiar modulated jitter, presumably related to increased processing load (I suspect the mechanism here may be different: i.e. an oscillator frequency shift related to voltage, rather than a voltage threshold issue).

One of the subsequent quirks I discovered with the TDC7200 is that you don't strictly need an accurate stop signal, because you can slightly misuse one of its measurement modes to obtain a time interval directly referenced to an external clock. So, at the cost of not being able to calibrate the TDC7200's internal latency, I can eliminate the issue of the MCU's clock jitter from my measurements.

I'll have a go with loading down the MCU, as the same TDC7200 measurement trick also permits direct measurement of the MCU's clock jitter. 

[WatchfulEye]

Well, that was easier than expected. I added a WFI instruction to the bottom of my program's main loop to put the MCU to sleep.

I have to admit I was more than a bit surprised when I extracted the clock skew measures from the logs and plotted the histograms. I don't think I need to add any commentary.

[PCB.Wiz]

Well, that was easier than expected. I added a WFI instruction to the bottom of my program's main loop to put the MCU to sleep.

I have to admit I was more than a bit surprised when I extracted the clock skew measures from the logs and plotted the histograms. I don't think I need to add any commentary.

Nice plots. I wonder how much the plots spread if you then enable the MCU PLL ( but still sleep) ?