Hello Justin,

Assuming your Kvco is correct, your loop filter looks stable to me. I doubt this is the problem.

Low probability of being related, but I recommend setting PLL2 N-Cal divider equal to PLL2 N divider, since right now PLL2 VCO range is being calibrated using 3000/16 as the feedback frequency instead of 3000/300. This would usually only affect PLL2, but it eliminates one extra variable.

As for your PLL1 problem, I can't find anything in your post that says the state of PLL2 lock detect. Since OSCin is used both as the PLL1 feedback and the PLL2 reference, which PLL is failing to lock is usually indicative of the source of your problem. If neither PLL locks, and unrelated misconfigurations of PLL2 have been sorted out (e.g. PLL2 N-Cal divider set incorrectly), this points to something happening at the VCXO; if PLL1 alone is failing to lock, this suggests the reference input is not being adequately captured.

A helpful tactic for debugging lock issues is monitoring what the reference and feedback paths at the phase detector are seeing. Instead of monitoring PLL1_DLD and PLL2_DLD on the lock detect signals, you can monitor PLL1 R and PLL1 N, and look for a stable signal.

All this is assuming there is an issue with locking. But based on your post, it sounds possible that there is some other issue happening, since I agree that it sounds implausible for the window detect to be oscillating at the rate described. I'd still be interested to see if the results of PLL1 R/N monitoring suggest the PLL is locking, and this is some state machine issue.

There is a bit, CLKin_OVERRIDE (R336[6] or 0x150[6]), accessible from the general controls in the user controls page. Can you try setting this to 1? Since you are using register-based selection of CLKin0, this bit may force the state machine into a stable state for clock selection... but I'm not sure why it would be required, other than due to some kind of bug.

Finally, are you seeing this issue on more than one device?

Regards,

Derek Payne

Hello Derek,

First of all thank you for such a quick reply. We appreciate your help.

With regards to which PLL locks we seem to see three or four different fail states. The first and most common state is shown in the scope captures in Justin's post. We see the lock bit for PLL1 oscillate, but PLL2's lock bit stays low other than the noise we found present on almost all the signals. The chip seems to go into this state most often. When the IC is very hot (45+ degrees C), it almost strictly fails into this mode. We have seen two other failed states; one in which PLL1 does not lock and PLL2 locks, and one in which PLL1 locks and PLL2 remains unlocked. Both of these states are much rarer, and were only seen on occasion (1/20 attempts) and only when the temperature was close to the 34-36 degree cutoff we described. The most common failure, the one we outlined in the first post, shows both PLLs not locking, but PLL1's lock bit oscillating and PLL2's bit remaining low other than noise.

In response to the N and R signal testing question. We have programmed the LMK to output PLL1's N and R clock signals and captured the response in both successful and failed states.

Trace 1(yellow) is the R signal, trace 2(blue) is the N signal, and again trace 3(pink) is the VCXO control voltage after the loop filter.

This capture shows a successful lock of PLL1 as well as PLL2:

Here is a smaller timescale capture of the same signals:

We see the two clock signals start out of phase and adjust into phase as the control loop hunts for lock, once the control voltage settles we see the two signals locked as we would expect. I assume the smaller period of the N clock is due to the 10x division occurring after the VCXO and before the phase detector?

The interesting thing is that when the chip goes into the failure mode we described, the N and R signals are no longer present at the LD1 and LD2 outputs. We were puzzled by this, as we expected the IC to still present the clock signals regardless of lock state. We confirmed that both clock's were still operational and had valid logic levels and slew rates in this state.

Capture of a failed lock (above threshold temp) showing no N or R clock outputs:

On a slight tangent, we attempted to validate our capture range of PLL1 out of fear that the VCXO was possible drifting too far to be locked with the reference. We provided an external reference signal to the PLL1 reference input by modifying the CLKin_MUX and connecting a signal generator. We then began increasing and lowering this input references frequency to make force the PLL to have to seek further in the pulling range of the VCXO. With the board cold we saw the PLL successfully lock throughout the control voltages range with reference frequencies deviating 1000Hz or more. We believe this proves that the slight frequency drift we see on the VCXO due to thermals is not a factor in the instability of the LMK. The PLL1 loop is sufficiently tuned to provide a more than adequate capture range. Please advise as to if our testing logic here is valid.

Trace 1(yellow) is the PLL1 lock signal, trace 2(blue) is the PLL2 lock signal, and again trace 3(pink) is the VCXO control voltage after the loop filter.

Capture showing the PLL locking at the higher end of the VCXO pulling range:

Capture showing the PLL locking at the lower end of the VCXO pulling range:

When the reference was skewed beyond the pulling range of the VCXO we saw lock instability as we would expect. But the failure mode was closer to expectations. Intermittent PLL1 locks as the charge pump reached the limits of the control voltage output.

Instability as the VCXO is at its upper frequency limit:

Instability as the VCXO is at its lower frequency limit:

We are seeing this failure on multiple boards from the same revision. We also have seen this failure on previous revision of the design with the same clock generation circuit. The full code on the package of the chip we have been testing is 94A3ECUG3 K04828BISQ.

Thank you again,

Spencer

Spencer,

It is quite surprising to me to discover that there is no clock signal at all while the device is in the anomalous state. If nothing else, the R-clock should be present as long as there is a reference selection forced. The fact that you can lose both R/N clocks at some temperature threshold suggests there's something going on unrelated to the PLL behavior, like the logic circuit is failing or losing power above some temperature.

Spencer Drewry said:

I assume the smaller period of the N clock is due to the 10x division occurring after the VCXO and before the phase detector?

Yes, the phase detector looks at edges so duty cycle after the divider isn't critical.

Spencer Drewry said:

Please advise as to if our testing logic here is valid.

This experiment makes sense, and as far as I'm concerned it rules out the VCXO pull range as an issue.

Spencer Drewry said:

We are seeing this failure on multiple boards from the same revision. We also have seen this failure on previous revision of the design with the same clock generation circuit.

This is also quite surprising, and leads me to assume that there is something systemically wrong common to both revisions of the design.

Follow-up questions:

• If you configure the startup programming such that PLL1 is powered down completely, does PLL2 lock consistently at hot temperature?
• I didn't see you mention it, did you try this test with the CLKin_OVERRIDE bit set?
• When probing the supply lines, did you probe the pin voltages on the package, or somewhere nearby e.g. after the ferrite? I am wondering if something is preventing the part from soldering to the board, and you have intermittent contact on one of the supply rails.
• Is it possible for me to see the layout of the clock generator circuit?

Regards,

Derek Payne

Hi Derek,

Thanks for your continued support. We ran the suggested test cases, and continued to see the same dependency on temperature.

Derek Payne said:

If you configure the startup programming such that PLL1 is powered down completely, does PLL2 lock consistently at hot temperature?

No. With PLL1 powered down and CPOUT1 tri-stated such that PLL2 uses the raw VCXO as its reference, the LMK continues to exhibit the same behavior of PLL2 locking (observed with LD2 = 1, LD1 = 0) at cold boot, and funky oscillations on LD1 and LD2 at hot boot.

The first image below is of a successful PLL2 lock at cold with PLL1 disabled. Yellow = PLL1 Lock, Teal = PLL2 Lock, Pink = CPOUT1 (tri-stated).

The second image is of an unsuccessful PLL2 lock at hot boot and the same register configs. Yellow = PLL1 Lock (expect to be 0, but oscillates up to VCC). Teal = PLL2 lock, Pink = CPOUT1 (expect to be tri-stated but is similarly oscillating).

Derek Payne said:

I didn't see you mention it, did you try this test with the CLKin_OVERRIDE bit set?

We attempted the CLKin_Override bit set to 1 and continued to see the same behavior.

Derek Payne said:

When probing the supply lines, did you probe the pin voltages on the package, or somewhere nearby e.g. after the ferrite? I am wondering if something is preventing the part from soldering to the board, and you have intermittent contact on one of the supply rails.

Here is a probed supply line after the ferrite (VCC11_CG3) in the fail state. In the fail state, VCC looks really, really bad at 3.3Vdc with 1Vpp swing, though I'm not sure if this is a shortcoming of the supply itself, or the LMK chip is clamping the supply due to a hot fail state. Yellow = PLL1 Lock, Teal = PLL2 Lock, Pink = CPOUT1, Dark Blue = VCC11_CG3

During the successful cold lock state, the same point probed is at 3.3Vdc and much quieter. It does still seem to get noisy under activity (250mVpp) before PLL1 is fully locked. Pic 1 = Zoomed out, Pic 2 = zoomed in on first trigger of PLL1 Lock.

.

Our next test in this category will be to retest with external power sourced to the LMK and VCXO (essentially bypassing the TPS7A4701 LDO), and depending on results, may dead bug a higher capacity LDO to eliminate chance of brownout. In our TICS model, the LMK draws 630mA, while the LDO is sized for 1A output.

Derek Payne said:

Is it possible for me to see the layout of the clock generator circuit?

Top Side Layout:

Bottom Side Layout:

Another tangent: we determined that the cause of seeing oscillations at 5MHz or 10MHz was due to aliasing on the scope. All the oscillations in the fail state have a 100MHz frequency.

Justin,

I am coming up with closer to 800-870mA depending on VCXO load and LVPECL termination, so I think swapping the LDO with a higher-current supply is a reasonable next-step. I don't know what the OCXO current is, but with 870mA from the clock generator and the OCXO seemingly on the same 3.3V LDO, I wouldn't be surprised if the current limit is being tripped.

If possible, you could try a simpler register-based test where the CLKOUTs are all powered down. Setting every CLKoutX_Y_PD=1 on powerup cuts the current by ~500mA. You wouldn't have output clocks, but you don't need output clocks to evaluate if the PLL locks successfully in the lower-current condition. You could also monitor the LDO current with all outputs configured for powerdown, and if this number + 500mA > LDO current limit, it is likely the current limit is the culprit.

The only other thing I could think of is the placement of the 50Ω termination for the VCXO might be injecting some 100MHz noise into the LDO ground. The LDO datasheet makes a somewhat vague statement that no voltage other than GND should be connected to the voltage programming pins, so I wonder if 100MHz ground noise is coupling into one or more of these voltage-setting pins and causing the LDO to rapidly cycle between certain output voltage settings.

Regards,

Derek Payne

Hi Derek, thanks for the suggestions. As advised, we tested power supplies, with the following starting assumptions:

We shared the same observation as you on the 50Ω GND termination of the VCXO to OSCIN potentially injecting local 100MHz noise into the LDO’s GND, so we attempted this rework, shown in Yellow below, where we “tombstoned” the termination cap and resistor and routed back to the VCXO’s GND. This did not change the performance of the PLL.

We also tried a number of test cases to rule out current limiting the TPS7A4701 1A LDO:

1. Fed external 5V at the input of the LDO so that we could monitor the total current of the LMK + VCXO. Total current going into LMK + VCXO was observed to be 700mA at max load.

2. Disabling all the CLKOUTs and SDCLKOUTs with register settings. We did not obtain a current measurement here, but the LMK’s PLL lock behavior continued to track to temperature.

3. Replaced the VCXO part with one that draws less current, and has the same frequency stability, pull ratio, slew rate. LMK PLL lock behavior continued to track to temperature.

4. Replaced the 1A LDO with a 1.5A LDO dead-bugged onto the PCB with extra decoupling. LMK PLL lock behavior continued to track to temperature. We did get a new occasional failure mode after the LDO change in which the LMK continues to run the CPOUT1 loop (Pink) even after the PLL1_DLD (yellow) and PLL2_DLD (blue) start oscillating.

At other times even with the LDO rework, the LMK did not enter the control loop during the DLD oscillations, matching previous results.

Lastly, we removed the LMK part (original lot code: 94A3ECUG3 K04828BISQ) and re-soldered a different lot code (0AAKRFUG3 K04828BISQ) part onto the board. Even with the new part installed, the LMK continued to successfully lock at cold and not at hot.

One last tangent: we confirmed that some of the oscillations on the LMK’s digital lines were in fact NOT scope aliasing as we believed yesterday. We set the trigger on CH1 (STATUS_LD1), and an LMK in the hot mode did oscillate at 3 different frequencies, as shown below.

Thank you again for your continued support, Derek.

Justin,

This is quite bewildering. Let me run it past a few other people internally in case they've ever heard of anything like this.

Regards,

Derek Payne

Justin,

After discussion, there's a few things we're thinking could be at issue, related to somehow triggering a reset event or a supply brownout.

• The RESET pin connection is not shown, so I'm not sure what's driving it (MCU? Tied high/low elsewhere?). We could try disconnecting the RESET pin and configuring the RESET_TYPE as an output. This eliminates one major path for resets on the device.
• I notice that the capacitors after the ferrite beads for Vcc7/8/9 are omitted, but footprints for these capacitors are present. Has anyone tested populating these capacitors? There is a bullet point in the datasheet for section 11.1.1.1 which suggests frequencies >30MHz can use the ferrite bead with internal capacitance, but considering the supply voltage ripple on the other supply pins, that capacitance may be required for some high-current portion of a reset event that was overlooked.
  • Our EVMs actually do populate these capacitors, despite a default VCXO frequency of 122.88MHz. It's possible that the failure mode we're encountering now was never observed because these capacitors were never really omitted.

If neither of the above remedies makes a difference, can we get a readback attempt from a successful and failed lock case, showing the difference? You may also want to probe the MISO line during the failed lock readback transaction, as I have a suspicion that one or more supplies are browning out and the readback may not be clean SPI data any more.

Regards,

Derek Payne

Hello Derek,

We went ahead tested both of your suggestions in the last post, unfortunately to no avail. Adding the DNP'd filter capacitors had no change on the behavior.

In a previous test we changed the reset line to an internal pulldown mode. In an attempt to ensure this wasn't the issue we also added a stiff external pulldown of 1K as well as a filter capacitor of 0.1uF. Neither of these modifications changed the failure mode of the circuit.

We will look into getting a SPI read off of the IC while in the failed state. Though I assume it will likely fail due to the chips state, as you mentioned. We have moved forward in our investigation by taking steps to generate a development PCB with multiple layouts of the clock generation circuit as well as some new layouts. Hopefully this will lead us to a discovery regarding the root cause of this instability.

Thank you again,

Spencer

Spencer,

Understood. Apologies that we didn't have any great answers for you this time. Let us know if you find anything surprising.

Regards,

Derek Payne