LMK03318: The clock PLL is unstable

Hello Xin Li,

Please advise what frequency was being input to device, as well as voltage level. After PLL became unstable was the output of the LMK00301 checked or the input to LMK00301?

Using the attached register in TICSPRO shows me that the Fvco probably was not set correctly as Fvco of LMK03318 should be between 4.8 - 5.4 GHz.

hello Aaron:

                    Use the oscilloscope trigger mode, green is status 0, 1 is lock out and 0 is locked. Orange is the signal point tested before the AC coupling capacitor at the input of LMK03318. Green is the input of lmk00301, which is a 10MHz single-ended sine signal. When the lock was lost, no fluctuations in the clock were seen. We also tested 1.8v and 3.3v power supplies, and there was no jitter or other abnormalities when the lock was lost. Do you have any special suggestions? Looking forward to your reply, thank you!

hello Aaron，

                    Our design Fvco is 5GHz,，as follows ，Is there any problem with the register configuration? Please explain in details.

       I want to ask a question. According to the instructions in the manual, if it is external LVDS AC coupling, LMK03318 needs to enable           TERMINATION and BIASING internally. When I select "diffterm_pri" and "AC mode pri" at the same time. The register is configured as 0X1D05, the indicator light of the statues1 will indicate no input. When I only select "AC mode pri" and the register configuration is 0X1D01, I can measure that the common mode voltage is 1.8V, and the configuration takes effect. The indicator of the statues1 is normal, showing that PRIREF has input. I don’t understand that it’s not OK to select it at the same time.

Statues0 and statues1 are connected to external lights as lock and input indication signals, both of which are active low and the lights are on.

The clock structure and clock level are as followsThe clock structure and clock level are described in the following figure.   

waiting for your reply, thank you！

Hello Xin Li,

There are a couple of things we can check both are related to the PRI S-E Detect Mode, #1 should be tested first then #2:

1. Please set PRI S-E Detect Mode located in the 'Inputs/PLL' tab to Vih/Vil Level detect

2. Keeping PRI S-E Detect Mode to Vih/Vil change PRI Diff Detect Level to 300 mVpp Diff swing and 200 mVpp.

The reason why this might be having an issue is because currently Loss of Signal is set to 'Slew Rate Detect' and this has seen an issue in the past.

Hello Xin Li,

Please watch the LOS Status as well as the LOL Status to make sure we are maintaining a valid input - from the device's perspective.

You can utilize the same oscilloscope setup you had previously just add another connection to detect LOS as you did with LOL or remove connection to buffer input.

We also could check both the N and P side of the input, this might be helpful.

hi  Aaron,

I changed the input to LMK00301 to square wave input. LMK00318 lock is much more stable than before, but some boards may lose lock several times. I would like to ask how to enable the input 100 ohm internal termination. When I enable “diffterm_pri”,wrote Register R0x1D as0x1D87, Statues "PRIREF LOS" will be detected without input. How can I enable internal termination?

Hello Xin Li,

Please see section 10.4.2 of the Datasheet discussing the Universal Input Buffer available on PRI_REF and SEC_REF for a visual and Table 4. Input Buffer Configuration Matrix on Primary and/or Secondary Reference for refence.

This table explains what registers to change (Register 50 [0x32] and 29 [0x1D]) based on what 'Mode' and 'External Coupling' you would like to utilize.

From Register 0x1D setting of 0x87 you have chosen Internal Biasing / External AC Coupling and therefore External Coupling should be provided (Internal Biasing will be the same setting for all Modes). Has this case been met? Please share Register R13 settings.

Hello Aaron,

I have seen section 10.4.2, the current design meets the LVDS external AC coupling, but after enabling the internal termination and bias, it detects "priref los" no clk input, I can confirm that the internal bias is enabled, but The internal termination does not seem to take effect.
Also R13[0X0D00].

Hello Xin Li,

Register 13 also looks like it is set correctly. If what you are claiming is correct, when you read back the device the settings of Register 50 (0x32) and 29 (0x1D) as well as the REF_SEL pin are all set to utilize PRIREF, correct?

I think another read over of section 10.4.17 to 10.4.18.2 will be helpful. I will do this myself, sorry you are experiencing such a tedious issue.

hi  Aaron,

Thank you for your reply. I tried to enable both "Diffterm_pri" and "Diffterm_sec" [0x1D0F]. The test found that the internal 100 ohm termination was enabled. It seems that only enabling one of the terminations (only "Diffterm_pri" or only "Diffterm_sec") the internal 100 ohm termination does not take effect. 

The section 10.4.18.2  “The PLL’s loss of lock detection circuit is a digital circuit that detects any frequency error, even a single cycle slip. The PLL unlock is detected when a certain number of cycle slips have been exceeded”    When the above situation occurs, can the clock continue to be output? Instead of losing the lock and not outputting the clock, I tried to set R22 CH_0_MUTE to CH_7_MUTE to 0. Is this configuration OK?

Hello Xin Li,

If you enable both 'Diffterm_pri' and 'Diffterm_sec' has this correctly enabled 100 ohm termination?

If you would like to continue operation after Loss of Lock you can utilize R23 and set these bits to '0', if '1' is set the the STATUSx Output will be automatically disabled when the selected clock source is invalid. Please also note. you can utilized a slower STATUS1 or STATUS0 slew rate output through R49 which will help reduce coupling onto your high-speed outputs.

Aaron Black said:

If you enable both 'Diffterm_pri' and 'Diffterm_sec' has this correctly enabled 100 ohm termination?

yes

Hello Xin Li,

Are you still seeing your issue or is this resolved?

When it is detected that the clock signal is out of lock, the system clock to ARM will not be output, (even though I set Channel MUTE to 0) ARM's startup and work will be affected in some cases. This happens occasionally in the current test, and I am still paying attention to this issue. Observation and pressure testing are underway.

Hello Xin Li,

Please keep me updated with your observations I'll have to ask the internal team if they have seen this.