Timing stability of MCU PLLs

[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) ?