PLL Reset Information

[vk6flab]

I noticed the comment on PLL reset in your README.md and thought of an email by Hans G0UPL who uses the SI5351 extensively in several projects. His email goes into depth on the topic:

https://groups.io/g/BITX20/topic/si5351a_facts_and_myths/5430607

I'm not sure if you're familiar with it or not and ticket this isn't a bug-report or even a feature-request, just sharing some information that might be of benefit.

[MR-DOS]

Yes, I read that topic while writing my library. However since my library is intended to be used by someone who understands the chip and doesn't want the library to stand in their way and do unexpected things (except for the automatic low-jitter mode enabling automation), I figured that it will be better left to the user with proper word of caution.

In fact, it is even more complicated. You need to use the reset in many cases, but beware:

• When you want any two outputs sharing one PLL but having either different multisynths (the smart dividers) or different R dividers (oh yes, you can connect R dividers to other MSs given that Rs 0-3 can only be connected either to their own respective MS or MS0 and Rs 4-7 to their MS or MS4 and you have to enable a special unexplained bit to allow this interconnection, see AN-619 v0.7 corrected by me, but I'm getting detached...), then after reconfiguration, you need to perform PLL reset. Funny thing - PLL reset unlocks the PLL for a while but also resets MSs, R dividers and clock outputs connected to it. Not sure what it does to things not connected to it though. The reason is that THE CIRCUITS AFTER THE PLL get out of sync. The PLL actually has no reason to be reset anytime. Just the circuits behind it, but you can't choose.
• When you reset any of the two PLLs, they get out of sync. Say you have both PLLs set to exactly same frequency and they are magically in phase at the beginning. After resetting one of the two PLLs, it ends up having random phase with respect to the other PLL. If you were to test it, I would expect that the reset takes some time which may (or may not) have a form of gaussian pulse with some center lock time and some spread. Sadly, I do not have any interest or enough time to test this hypothesis. Certainly it is interesting and seeing the resulting graph would make me happy and make me say "Oooh, I thought so." but since it is only probabilistic parameter and I need exact values for my purposes, then it may serve only as a way for getting a first guess of how the phase will look after reset but then again... it may save some time but it requires that you knew the phase offset before the change which might not be possible.
• Actually you don't need to reset after disabling output clock, that was a bit of misunderstanding from Hans. Well, that is if you only DISABLE it, not POWER DOWN it! There is a difference and there is a reason why there are separate bitfields for these two operations. Powerdown disables the R dividers so power up causes phase offset.

It is difficult to state any precise conditions when it has to be reset because documentation is bogus. I really don't want to force resets when not needed in the software. If you use it and find that you need a reset under specific conditions, then implement it yourself for just that case. The chip allows for many unexpected things like allowing about 5x larger spread for spread spectrum with no problems. Or tuning the PLL between 300 to 1000 MHz. Or disabling certain clock paths to lower the power consumption. Or change PLL tuning capacitor so the PLL gets more stable when clocked at <600 MHz. Or you can watch some clock dropout flags which only appeared in AN-619 after I was asking about it. Documentation from SiLAbs really gets funky sometimes. The Si5351 is one of the worst cases. One of them, there is for example the SI5341. It used to boast the ability to set phase offset of outputs in tens of picoseconds. Exactly what I needed for my purposes. However, there was a strange mention on one page. I asked on the forum. It turned out that... oh yes, you can set the offset in steps of maybe 20 ps... but there is a nondeterministic thingamajig going on when it's getting configured which causes a tolerance of that setting on the order of nanoseconds, thats's 100x more than the resolution! So, I cannot exactly tell when the reset should be used. Maybe if I use the part once again (probably the MS5351 clone due to availability), I may make an oracle function which will tell you whether it recommends you to reset or not. And a function to enable "magic oracle-based" resets.

TL;DR: Documentation of Si5351 is a circus and I needed the library to be deterministic, predictable and not bothersome, so resets are manual now. An oracle to predict resets and automatic oracle-based resets may be implemented later but I cannot guarantee it. I am aware of these problems since they were there since the beginning of this library. Sorry for that but it is what it is.