I'm testing the Si5326 for regenerating a noisy 12 KHz clock. I have read previous notes that the input to output skew is nondeterministic on the Si5326, but in my testing the variation in skew is very small relative to my clock period and I think is probably not relevant for my application. However, I am having trouble zeroing the phase delay.
Looking at "220.127.116.11. Unlimited Coarse Skew Adjustment (Si5326, Si5368)" in the reference manual, there is a procedure outlined that iteratively adjusts the CLAT and INCDEC pins to shift the phase delay by 25ns ever 15 or so seconds. While this does work, adjusting a 12 kHz clock at this rate of tuning takes forever due to the extremely long time to for the CLAT changes to lock and the small adjustment per lock, and of course the results are lost when the device powers down and the entire lengthy process must be repeated.
Is there anything I can do to more rapidly adjust the phase delay? I do not require extremely low phase offset between the inputs to outputs.
Thanks for questions, you have dive into it deeply. No other fast methods.
Do you need zero delay mode? If yes, the Si5342/44/45 series has an additional zero delay mode so the input to output skew would be low upon power up/reset/ICAL as well as when locked up.
Zero delay mode would also work, but looking at the Si5342/44/45 series it looks like that is not recommended below 128 KHz input. I've seen some mention that it might work at 48 KHz, but wasn't sure if they were an option for my 12 KHz clock.
I've seen some mention that it might work at 48 KHz, but wasn't sure if they were an option for my 12 KHz clock.
That "mention" was likely from me. The tools would not allow the use of a clock at that rate (actually I was interested in going down to 44.1 kHz) and I opened a support case asking whether the tools could be overridden to allow for this, and also what the implications were for doing so.
The answer was that at frequencies below 64 kHz the zero-delay mode does not meet the 110 ps delay spec in the data sheet. Further, the support engineer suggested that the delay would be "better than a nanosecond" at 48 kHz. For audio word-clock synchronization, that's more than good enough!
The support engineer modified my Clock Builder project file to allow inputs down to 32 kHz. The design based on this is working well.
Perhaps open a test case and suggest that modification.