This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK05318: How to clear LOPL_DPLL

Part Number: LMK05318

Hi,

We are currently using LMK05318RGZT in our board and we are trying to produce an output clock identical or as close as possible to the input clock.

We have 48MHz crystal on board that drives the XO input of the LMK05318

Using the TICS Pro software, we are able to see that LOPL_DPLL and sometimes LOFL_DPLL are set.  Occasionally they are not. 

I found that with adjusting the DPLL Frequency and Lock Detect Thresholds, I can sometimes get a clean signal (no LOPL_DPLL, no LOFL_DPLL). 

Other times it will not work unless I toggle between PRIREF and SECREF.  When I toggle, the DPLL is somehow able to lock onto the incoming clock (both LOPL_DPLL and LOFL_DPLL are cleared).

How can I make it so that neither LOPL_DPLL or LOFL_DPLL are never set? Why would LOPL_DPLL or LOFL_DPLL lock on when toggled?

Thank you for your help and I hope to hear back from you soon.

-Gavin

  • Hi Gavin,

    LOPL and LOFL stand for Loss of phase lock and lock and frequency lock. It is not recommended to tweak the phase lock thresholds to get phase lock, because that way it won't be real.

    If your input is not 1pps then there shouldn't be much difficulty getting both LOFL and LOPL cleared. Still, I strongly recommend that you use the LMK05318B profile. You need to download the latest Ticspro and in the first wizard page, select "backward compatible" to generate LMK05318 configs.

    In that wizard, you will find answers to all the questions you may have, including meanings of frequency / phase lock settings. In the last wizard page, you'll find explanations of status registers.

    As for your questions, since there's no straightforward answers to "why the DPLL doesn't lock", please first go through the LMK05318B wizard and follow the instructions there.

    Regards,
    Hao

  • Sorry, one correction: loss of frequency lock.

  • Hi Hao,

    Thank you for getting back to me. Are you saying I should switch the ppm values back to their original value?

    I am currently using a LMK05318RGZT, so I am not sure if the LMK05318B would fall under the same category.

    Would the TICS Pro profile for LMK05318B work for my device?

    You also mention this: "If your input is not 1pps then there shouldn't be much difficulty getting both LOFL and LOPL cleared." Do you mean this with the original unchanged settings?

    Thank you for your help and I hope to hear back from you soon.

    -Gavin

  • Hi Hao,

    I tried using the LMK05318B profile and went through the wizard but there are a few things I was unsure about since I did not see it in the LMK05318 wizard.  For instance, the DPLL settings are a bit different.

    Unlike before, there is reference validation, and the "Set DPLL" page.  Am i led to believe that I am not supposed to change these things?

    I left the default values for the reference validation and "Set DPLL" page as is since you said not to alter those values in your previous message.
    With this configuration, I was not able to get my clock output at all.  Was that a mistake?

    All I want is a 100MHz output that uses the SECREF as a reference clock.

    Thank you Hao, I hope to hear from you soon.

  • Hi Gavin,

    Sorry you've been having so much trouble with the LMK05318B wizard... just to be sure, you are running the script to generate the DPLL configuration, correct?

    I think if you have an idea what's causing the LOPL and LOFL conditions in the first place, it will help in identifying and eliminating the source of the problem.

    LOPL/LOFL will both get invalidated if the PRIREF/SECREF signals are simultaneously invalid. One possibility is that your PRIREF/SECREF validators are declaring the signal invalid. You can check if the signal is validated on the status page, under "Other Status Registers" - PRIREF_VALSTAT and/or SECREF_VALSTAT should be checked whenever the references are valid and the status is read back. If you see that PRIREF_VALSTAT or SECREF_VALSTAT are getting cleared while the device is running, this suggests that one of the detector criteria is not being met. You can go to the reference validation page on the LMK05318B, or to the start page and the equivalent validator settings on the LMK05318, and disable combinations of validators until you find the validator that's failing. From there you can take corrective actions like updating the validator settings or leaving it off if it's unnecessary, or potentially correcting the input if it's actually invalid.

    Another possibility is that the XO signal is intermittent or corrupted, which is throwing the VCO off. You can check if the XO signal is misbehaving by programming one of the status pins as PLL2 R div-by-2 signal, and looking for missing/extra pulses, large frequency deviations, etc.

    Another possibility is that, if the XO isn't very stable (e.g. drifts by more than 100Hz/s), the DPLL loop bandwidth could be lower than the XO drift, which would cause the APLL to drift quicker than the DPLL can correct. You can try increasing the DPLL loop bandwidth and re-running the script, which should improve the accuracy with which the DPLL tracks XO wander.

    After trying all of this, if you're still having trouble getting the DPLL to lock consistently, please upload your configuration to us for review as a .tcs file (Save menu option, not export registers option) and we can take a look for any remaining issues.

    Regards,

  • Hi Derek,

    Thanks for getting back to me.  When you mention the script to generate DPLL configuration.. is there a separate script to generate the DPLL config, or do you mean the one on the "Set DPLL" page?  If you mean the one in the wizard, what values would I need to alter to produce my desired output?

    Again, all I want is a 100MHz output that uses the SECREF as a reference clock, so is there anything I would need to alter?

    Thanks and I hope to hear back from you soon.

    Best,

    Gavin

  • Hi Gavin,

    I mean the `Run Script` button on the `Set DPLL` page. I think the default settings should be sufficient (Target = 100Hz, Tr peaking = 0.1dB, Er peaking = 1dB). If the XO isn't particularly stable, you could try bumping the target loop bandwidth up to 300Hz instead, then running the script again.

    If you don't need the digitally controlled oscillator function (DCO; probably the case, sounds like you're not planning to manually tune the frequency), you can try setting the DPLL pre-divider to 5 and the N-divider to 10 (numerator = 0) after running the script as well. While the DPLL has a fractional N-divider, when you aren't using DCO the divider can be used as a standard integer divider which should improve the performance once it's locking consistently, and removes one extra variable from the reasons why it might not be locking.

    On the `Set DPLL (cont.)` page, I'd try the `Set Default` button for the DPLL frequency lock, and the `Recommend` button for the phase lock. The rest can be ignored for now.

    One other note: after you've got a configuration that you think should be correct, I find the most consistent procedure for programming the device to be clicking `Soft-reset Chip` in the toolbar at the top of the page, then pushing Ctrl-L or clicking `Write All Regs` to write all registers. Occasionally the DPLL state machine can get into a strange state if the DPLL values are being modified while the device is running.

    Regards,