LMK5B12204: PLL Lock

I have observed similar behavior with the LMK05318B when VDDx was not decoupled sufficiently.
The recommended VDD and VDDO bypass capacitor value has changed from 0.1μF to 10μF.

Also check XO frequency tolerance. When XO frequency offset is too big, the TDC will not capture the ref whitin its range.
Experienced that the frequency lock can then take a very long time, as in your case, several hours.
After adjusting the VC-OCXO closer to the reference frequency, locking was completed within a few minutes.

Hi Octo,

We are using 10 µF and 0.1 µF capacitors. The configuration is similar to the one shown on page 74 of the datasheet. The TCXO is 19.2 MHz ±500 ppb.

I have discovered one thing: when I change PLL1_MODE in R116 to Freerun mode, the values in R114 to R110 return to their original states, whereas they were previously all zeros.

Thanks

Yoshinori

So the capacitors and XO tolerance are fine.

R110-R114 look like expected behavior to me.

R110-R114 and R123-R127 are for the DPLL feedback divider.

I just reproduced it on my custom designed board. With PLL1_MODE=0x00 the clock outputs became free running with following register values.

PLL1_MODE=0x00

R110-114: 0x d5555631 18446744072993723953
R123-127: 0x d5555631 18446744072993723953

PLL1_MODE=0x01 after freq lock

R110-114: 0x d5555631 18446744072993723953
R123-127: 0x d547c221 18446744072992834081

If my calculation is correct the ratio is: 18446744072993723953 / 18446744072992834081 = 1.00000000000004840572

So my OCXO has this ratio relative to the reference frequency. This ratio should quit stable and around 1.00

Hi Yoshinori, 

If PLL1_NUM_STAT is reading back as all 0's, that usually indicates that there is some mismatch with the actual PRIREF/SECREF frequency compared to the expected value. Can you attach your .tcs configuration file? Also after loading your config to the device, do you issue a soft reset? 

Regards, 

Connor 

Hi Connor,

Upload the .tcs file.

If the reason PLL1_NUM_STAT is all 0s is a mismatch between the input frequency and the settings, it seems likely that the TCXO's frequency is fluctuating due to temperature changes, so we will check this. 

We will check again to make sure the soft reset was performed correctly.

LMK5B12204_Setting.tcs

Hi Yoshinori, 

Thank you for attaching the configuration file. I noticed that the APLL1 charge pump gain is only set to 100uA, do you see any different behavior if you increase this to 800uA? I can also try using your configuration on my setup tomorrow and see if I can replicate the same behavior that you're observing. 

Hi Connor,

We are using a soft reset.
1.
We set the APLL1 charge pump gain to 800 µA and 1500 µA and checked the behavior.
There was no change in the phenomenon.
2.
We heated the board before powering it on.
There was no change in the phenomenon.
3.
We wrote the stabilized values of R123–R127 into R114–R110 and checked the behavior.
There was no change in the phenomenon.
4.
We heated the board before powering it on.
Then we wrote the stabilized values of R123–R127 into R114–R110.
In this case, R123–R127 did not drop to zero, and the device locked immediately.
The TCXO we are using is TG2016SMN 19.2000M‑MCGNNM.
Is the performance of the TCXO insufficient, or is there an issue with our settings?

Thanks

Yoshinori

Hi Yoshinori, 

Thanks for providing the additional details about your test setup. I checked your .tcs configuration on my setup and I was able to lock to a 1pps reference without any issues, so I don't believe this is a configuration issue. The TCXO you're using should also have good enough performance to allow the DPLL to lock to the 1pps reference. 

Have you verified the frequency accuracy of the 1pps signal that you're attempting to lock to? Could you also read back the status for the fields shown on the "status" page in TICS Pro? I'm mainly interested to see if your PRIREF input is being validated and if the device is successfully exiting holdover. 

Hi Connor,

I will verify the accuracy of the 1PPS.
Here is the current status:
R13: 0x00
R14: 0x0C ⇒ 0x80
R80: 0x00
R357: 0x28
R367: 0x28
R411: 0x08
Does this provide enough information?

I’m curious about R80.

Just in case, I am also sharing the 1PPS generation process:
The AM6411 receives and synchronizes with PTP. It then uses Time Sync Routers to output the 1PPS from SYNC0_OUT.

Thanks

Yoshinori

Hi Yoshinori, 

Thanks for sending the register readback. Regarding your question about R80, it's expected that BAW_LOCK = 0 since the BAW frequency lock detect feature is disabled in your config. We generally recommend leaving the BAW frequency detector disabled when using the DPLL as explained in the TICS Pro GUI:

"BAW_LOCK detector indicates if APLL1 (BAW VCO or VCBO) has locked to the XO input. This detector is not useful when the DPLL is locked because the VCBO tracks the xxxREF input in this state instead of the XO input" 

Looking at the readback value value of 0x08 for R411, this indicates that the SECREF input is valid but PRIREF is not. However this isn't expected since the SECREF input should be disabled in your config and only PRIREF should have a 1pps input. Can you confirm that R251 is set to 0x03 to ensure that the device is in manual holdover mode with PRIREF selected? 

Hi Connor,

"R411" was a typographical error. The correct value for R411 is 0x04. R251 is 0x03.

I apologize for the inconvenience.

Thanks

Yoshinori

Hi Yoshinori,

Got it, thanks for confirming. Sorry for the back and forth but can you also check R167? R167[1:0] should read back as 0x1 to confirm that PRIREF is the selected reference for the DPLL. 

Assuming that the DPLL is successfully exiting holdover, then I think the next step is to confirm the frequency accuracy of the 1pps source. 

Hi Connor,

"R167" (offset = 0xA7) is 0x01.

The 1PPS signal was observed on an oscilloscope.
Triggering was performed on the rising edge, and the waveform was checked 1 second after the trigger.
Variation was within 100ns.
We will now compare this with the 1PPS output by the grandmaster to confirm synchronization.

Thanks

Yoshinori

Hi Yoshinori, 

Sounds good, let me know if you're able to confirm synchronization between the input and output 1pps. Since the device is successfully validating the PRIREF input and exiting holdover, I expect that it should be able to achieve lock unless there's some kind of frequency error on the 1pps input it's attempting to lock to. 

Hi Connor,

The 1PPS output from the grandmaster and the 1PPS input to the LMK5B12204 (which is output from the AM6411) were synchronized.
However, there was one waveform that concerned us.
The 1PPS signal input to the LMK5B12204 did not have a 50% duty cycle.
It had a high period of 1 ms, with the remaining time being low.
We plan to change it to a 50% duty cycle and check again,
but is it possible that this issue is related to the current problem?

Thanks

Yoshinori

Hi Yoshinori, 

It should be ok if the input 1pps duty cycle is very low. I'll need to double check if we have an exact spec for this LMK5B12204 device, but for LMK5B33216 (a similar DPLL device), the minimum allowed pulse width for 1pps inputs is 100ns. 

Hi Connor,

The cause was not the duty cycle.
Even when the duty was set to 50%, there was no change in the behavior.
I have a question: Do you have any information about register R128 (0x80)?
When it takes time to lock, the value changes before and after the lock.
However, the register information for R128 (0x80) is not described in the LMK5B12204 Register Programming Manual (Rev. B).

Thanks

Yoshinori

Hi Yoshinori,

In the LMK05318B rev. April 2021 Programmer's Guide, R128 is mentioned.

On my board, freq/phase locked R128 has 0x00.

During holdover and locking progress it has also 0x00.

If i understand well, it is the calculation limit indication like carry flag.

Hi Octo,

Thank you for the information.
I observed R128 on the board that takes time to lock.
Before locking, it is 0x01.
After locking, it becomes 0x00.
I will investigate what is causing the flag to be set.

Thanks

Yoshinori

Hi Yoshinori, 

Apologies for the delayed response here, I was out of office last Friday. Like Octo mentioned, R128 includes the PLL1_NUM_SAT_HI/LO bits. If you're seeing that PLL1_NUM_SAT_LO is getting set, that indicates that the PLL1_NUM_STAT = 0 and is saturating. Generally this means that the PRIREF input has a large frequency error compared to the XO frequency which causes the DPLL to force an extreme numerator update in an attempt to lock to PRIREF. 

Just to confirm a comment you made earlier - you mentioned that the variation of the 1pps input signal was within 100ns. So is it fair to say that the long term frequency stability of your input is within +/- 100ppb? Or is it still possible that there could be some frequency offset? 

Another thing you could verify is that the LMK5B input receiver stage is correctly detecting the 1pps input. You could try setting one of the status pins to "DPLL R Divider, div-by-2" or "PRIREF Monitor Divider Output, div-by-2". My expectation is that this should output a 50% duty cycle signal with a period of 2s. If this isn't what you observe then there could be an issue with the input amplitude, common mode voltage, signal integrity, etc. 

Hi Connor,

I will upload an oscilloscope image showing the 1PPS signal input to PRIREF.
CH1 is the 1PPS signal output from the Grandmaster.
CH2 is the 1PPS signal sent from the AM6411 to PRIREF.
The trigger is set to CH1, and the persistence is set to infinity.
You can observe jitter between CH1 and CH2.
I captured the waveform for three minutes under these conditions.
From the observed waveform, the 1PPS appears to be synchronized with the Grandmaster.


Also, the jitter of the 1PPS stays within 60 ns, which corresponds to approximately ±30 ppb.


I will check “DPLL R Divider, div-by-2” and “PRIREF Monitor Divider Output, div-by-2” next.

Thanks

Yoshinori

Hi Connor,

1. I output “DPLL R Divider, div‑by‑2” to STATUS0 and observed it on the oscilloscope.
As you mentioned, I was able to confirm a 2‑second period signal with 50% duty cycle.
2. I output “PRIREF Monitor Divider Output, div‑by‑2” to STATUS0 and observed it on the oscilloscope.
Similarly, I confirmed a 2‑second period signal with a 50% duty cycle.

1.

2.

Is it reasonable to assume that there is no issue with the 1 PPS signal?

Thanks

Yoshinori

The observed values ​​and waveforms seem fine to me.

According to the waveform, the AM6411's 1PPS signal is indeed following the leader, and the observed ±30 ppb should also be visible in the ptp4l logs, as this represents the 1PPS output. These are normal figures for ptp.

The div-by-2 outputs (DPLL R Divider and PRIREF Monitor Divider Output) show no distortion. It's reasonable to assume there's no problem with the AM6411's 1PPS signal output.

BTW: 1PPS from grandmaster shows an impedance mismatch. I think it is caused by high slewrate or un-terminated link. But it was only for triggering the scope.

Was frequency lock achieved normally during these measurements?

Hi Octo,

It did not lock during the measurement.
Is it likely that the TCXO accuracy is poor?
I am currently exploring workarounds.
I’m considering adjusting the Phase Detector (Fpd) and the Fractional‑N Divider so that the initial value of the PLL numerator “N” will correspond to a frequency close to 0x8000000000.

Please let me know if there are any points I should be aware of.

Thanks

Yoshinori

It is likely that the TCXO accuracy is poor for some reason.
Temperature seems to have influence as you said last week.
Could the temperature have influence on the power supply?
Especially the TCXO power. In case of buck/boost-regulators, the switching frequency and voltage reference are more or less dependant on temperature.
TG2016SMN TCXO's clipped sine output is suspectable to supply voltage variation (Frequency/voltage coefficient 1.5 ppm/V)

TG2016SMN 19.2000M‑MCGNNM - Datasheet:
Supply voltage M:2.8 to 3.3V
Frequency / temperature characteristics C: ±0.5 × 10-6 Max
Operating temperature G: -40 °C to +85 °C
ST function N: Non
Vc function N: Non
Internal identification code (“M” is default)

But i found an important feature: Frequency tolerance f_tol ±1.5 × 10-6 Max.

With 1,64ppm jitter budget, locking to ptp is limited.
This TCXO precision is good but accuracy is poor.

Yoshinori, 

That's a good sign that the LMK5B12204 status pin correctly outputs a 0.5Hz 50% duty cycle signal, as that indicates the input receiver is correctly detecting the 1pps input signal. Like Octo mentioned there may be some impedance mismatch from the grandmaster since there's ringing/reflections, in the waveform but since it's not directly connected to the LMK device I don't think it should impact the lock behavior. 

LMK5B12204 can accommodate relatively small frequency offsets between the XO and PRIREF input, so in this case the TCXO precision (i.e. jitter or wander) is more important compared to the static frequency accuracy. The issue would only come in if the frequency offset with the 1pps input is greater than the +/- 100ppm tuning range of VCO1. Do you have some frequency counter that can verify the long term accuracy of the 1pps from both the grandmaster and AM64? Since both 1pps sources are locked with only 30ppb error with respect to each other I think it's unlikely that they could have >100ppm frequency error, but I'm struggling to come up with another idea why the APLL numerator is saturating during lock acquisition. 

I don't think it should be necessary to make adjustments to the fractional N divider to achieve lock, but you can try it and see if it has any improvement. 

Hi Octo and Conner,

I am still in the middle of checking various things, but I have noticed one point.
When all PLL1_NUM_STAT values become 0, R168 changes from 0x00 to 0x08 at the same time.
In the LMK5B12204 Register Programming Manual (Rev. B), this register is listed as Reserved.
Do you have any information about R168?

Thanks

Yoshinori

Hi Yoshinori, 

R168 corresponds to some DPLL status monitors, if it's reading back as 0x08 that also indicates that the DPLL is saturating.

One other question I forgot to mention, but have you already verified the free-running frequency accuracy when the LMK device is locked to the TCXO and the 1pps input is not present? 

Hi Connor,

Are you asking about setting R116 to 0x00 and observing the signal output from the LMK5B12204? If so, we haven't performed that test at the moment, so we'll see if we can check the signal with a frequency counter.

Thanks

Yoshinori

yes, with R116 PLL1_MODE = 0 or disable the AM6411 PPS output to find the TCXO's frequency tolerance in this specific case.
I think the TG2016SMN non-VC variant is not the best choice with Frequency tolerance f_tol ±1.5 PPM.

TG2016SMN Temperature stability 0.5PPM is ok and the VC-TCXO variant would be better to be able to adjust the free running frequency.

I'm curious to see what the frequency measurement will reveal.

Yoshinori, 

Correct, like Octo mentioned you can set R116 PLL1_MODE = 0 to disable the DPLL, or you could disable the 1pps output from the AM6411 to test the free-running frequency accuracy of the LMK5B when locked to the TCXO. Let me know if you're able to perform this test. At this point my best guess is that there's a large frequency offset between the TCXO and 1pps input which is causing the DPLL to saturate. However I expect that this would require a large ppm offset well beyond the 1.5ppm tolerance of your TCXO. On my setup when I loaded your DPLL configuration, I had to introduce roughly 800ppm of error between the XO and PRIREF until I saw the DPLL saturate and PLL1_NUM_STAT (R123-R127) converge to 0. So if that was the cause then I would suspect either the TCXO or 1pps reference would be operating far outside of the spec for some reason. Additionally, it shouldn't be possible to the DPLL to track such a large offset. Since the 1pps phase detector is enabled and the threshold is set to 63, it should only validate the 1pps reference if it has a maximum of 1.6us of error (i.e. 1.6ppm) with respect to the XO. 

Can you readback a register dump of these failing devices and confirm that it matches the config from the .tcs file? Also I know that you previously confirmed that you are issuing a soft reset after loading the config, but can you double check that you're following the other steps in the general register programming sequence as described in the datasheet? 

Hi Octo and Conner,

I measured the frequency of the 19.2 MHz TCXO.
For the units that lock immediately, the result was 19,200,001.x Hz*.
For the units where the issue occurs, the result was 19,199,991.x Hz*.
When outputting 19.2 MHz from a somewhat old signal generator, the measured value was 19,199,968.0 Hz.
* x: small fluctuation

Next, I set R116 PLL1_MODE = 0 on the units where the issue occurs and measured the output clock.
The output frequency settings were 27 MHz and 25 MHz.
25 MHz → 24,999,990.4 Hz
27 MHz → 26,999,989.5 Hz
The TCXO does not appear to be the cause.

I also checked the registers and the software reset, and found no issues.

One thing I did discover:
I output the following signals to STATUS0 and STATUS1:
0x40 = DPLL R Divider, div-by-2
0x41 = DPLL FB Divider, div-by-2
When the device fails to lock, these two signals were 180° out of phase.
After that, the phase gradually drifted, and I could see it attempting to adjust.

When the device locks immediately, the 0.5 Hz signals were nearly in phase.

How is the initial phase of the two signals determined?

Thanks
Yoshinori

Hi Yoshinori,

Focusing on 1PPS stability, I consider adding all tolerances to find the worst-case scenario.
The TG2016SMN TCXO has a Frequency tolerance f_tol ±1.5 PPM, the static offset of a particular device.
Added with the dynamic frequency offset fo-Tc ±0.5 PPM makes as much as ±2.0 PPM in extreme temperature cases.

PTP GM is generally locked to GNSS, which is convenient.
Assuming the PTP 1PPS from AM6411 SYNC0_OUT has ±100ns jitter.
It is composed of the ethernet PHY's XO (usually 25MHz XO), ptp4l pi algo and network PTP jitter (BC or TC).
To eliminate the ptp4l+network jitter you can try to kill ptp4l after it has reached stabilizing, say 1 minute. SYNC0_OUT will then produce a "calibrated" 1pps. (Otherwise you have the PHY XO tollarance of 50-100PPM)
with this little experiment, does it lock faster?

Regards,

Octo

How is the initial phase of the two signals determined?

Outputs lock to selected input clock frequency.
Outputs are un-muted if DPLL auto-mute enabled.
Configured DPLL bandwidth is asserted.
Output will have deterministic input-to-output phase
relationship if Zero-Delay Mode (ZDM) SYNC is enabled.

The datasheet shows "Zero-Delay Mode (ZDM) Synchronization" but it is actually the resetting of the output divider.
The LMK05028 has true zero delay mode operation.

Hi Octo,

Is this procedure equivalent to the verification method you proposed?
After PTP4l becomes stable, disconnect the network cable.
The PPS signal will enter a holdover state.
In that condition, check whether the lock time becomes shorter.

I interpreted your suggestion as follows:
By limiting the process that generates the PPS signal, the only remaining sources of PPS jitter are the jitter of the XO that is input to the AM6411 and the small internal variations that occur during PPS generation.
As a result, we can determine whether the PPS signal itself is the cause of the issue.

Thank you for the information regarding the zero‑delay mode.
I will investigate it.

Thanks
Yoshinori

correct, it is equivalent to disconnecting the network cable.
It's more convenient and possible to do remotely without going offline. Also the PHY XO offset can be found.
# phc_ctl eth0 freq

values are in nanoseconds and ppb's

Your interpretation is also correct. 

"The PPS signal will enter a holdover state."

Note that the AM6411 ptp hardware clock (PHC) enters holdover state and not the LMK.

Hi Yoshinori, 

Just wanted to add that the random phase that you're seeing could be introduced by the divide by 2 block which divides down the VCO frequency into the FB input of the TDC. However, I'm not sure why some units would consistently have a 180 degree offset at the TDC. You could try enabling the "DPLL_REF_SYNC_OUT7_NDIV_RST_DIS" field on the DCO and 1PPS sync page in TICS Pro. This should reset the TDC N divider on each rising edge of the PRIREF input which should guarantee deterministic phase between the R and FB paths. 

Hi Octo and Conner,

After PTP4l stabilized, the network cable was disconnected.
Once the PPS output from the AM6411 entered the hold state,
a soft reset was performed on the LMK5B12204 and its status was checked.
The lock time remained long.

Since the AM6411 can connect to a PC via serial communication,
there is no issue controlling it even without a network cable.

Is it correct that "DPLL_REF_SYNC_OUT7_NDIV_RST_DIS" corresponds to R252[6]?
I found this mentioned in the following document:
dr-download.ti.com/.../TICS_Pro_Release_Notes.pdf
If there is any documentation that provides an explanation of DPLL_REF_SYNC_OUT7_NDIV_RST_DIS, it would be very helpful.

Thanks
Yoshinori