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.

LMK04828B Deterministic Phase Relationship

Other Parts Discussed in Thread: LMK04828

I am having issues achieving a deterministic output from the LMK04828B device. My goals are to

  1. Establish a known, deterministic phase relationship between a reference clock and the output device clocks.
  2. Adjust the relative delay between the reference clock and the output device clock.

I have attached a copy of the block diagram. I am using two LMKs, with OSCin from pll1 of LMK1 feeding in to pll2 of LMK2; pll1 of LMK2 is unused. I am operating the LMKs in nested 0-delay mode.

My issue lies in achieving a deterministic relationship between the device clocks from LMK1 and the reference clock. The outputs from LMK2 and pll1 LMK1, however, have fully deterministic relationships. I cannot figure out why only one of three pll's used does not share this deterministic output. Instead, the position of the device clock outputs from LMK1, with respect to the reference clock, changes each time the system is rebooted. The device clock outputs to one of four positions, where one position is clearly favored above the rest, one is alternated to regularly, and the last two positions occur rarely.

I have tried changing the register configuration for the two such that they match exactly, nd still the output from pll2 (LMK1) is not deterministic. I have attached a dump of the register values. All of the registers match except for three of the readback registers (0x182, 0x184, and 0x185).LMK_configuration.pdf

  • You need to use cascaded 0-delay mode on LMK1, otherwise the VCXO phase is not deterministic to reference.

    Also note, the LMK04828/26 have GUIs released in the TICS Pro software which makes it simpler to use 0-delay. This profile and software will continue to receive updates in the near future.
  • Thank you for the quick response. Unfortunately that was a misnomer in my original post. I am in fact programming LMK1 to cascaded 0-delay mode as outlined in the manual and am still failing to achieve a deterministic relationship, hence my confusion.
  • Hello Adriana,

    I'm afraid I didn't get the dump of your registers, just your PDF diagram which shows the 10 MHz reference or external reference (10 MHz also?).  Can you re-attach the register dump?

    What is your VCXO frequency

    I'm wondering if the ratio N divider value / R divider value of PLL1 (or PLL2) reduces to ? / 4? 

    73,
    Timothy

  • Hi Timothy,


    Sorry for not including that, I had some issues attaching files when I first wrote the post.  We've currently restructured the code so that our output frequency is 300MHz. For LMK1, pll1 has an R divider of 1, an N divider of 10, and a fixed external VCO frequency of 100MHz. Pll2 has an R divider of 1, an N divider of 3, and a VCO frequency of 2400MHz. For LMK2, pll1 is not used, and pll 2 has an R divider of 1, and N divider of 3, and a VCO frequency of 300MHz. We are currently using the fixed, internal, 10MHz frequency as input.

    In the attached register dump, LMK2 is fully deterministic and pll1 of LMK1 is also fully deterministic. Pll2 of LMK1 largely favors one location but is still not deterministic.

    What is peculiar is that setting the R and/or N dividers for LMK 1 affects the phase noise of LMK2, and vice versa. Also, I seem to be unable to properly read and write from the registers on LMK1 until I read from register 0x003 first, otherwise I simply get a return value of 0x000 from any register I read/write to. I made sure to follow the programming sequence outlined in the manual so I don't understand how this is possible.

    Thanks,

    AdrianaLMK2_deterministic.doc

  • Adriana Calcutt said:
    In the attached register dump, LMK2 is fully deterministic and pll1 of LMK1 is also fully deterministic. Pll2 of LMK1 largely favors one location but is still not deterministic.

    Looking over the config, it seems these should be deterministic.  Before configuring the SYSREF_MUX for pulser on LMK1 or continuous on LMK2, did you go through a SYNC with the SYNC_DISX and SYNC_DISSYSREF bits = 0 and DCLKoutX_DDLY_PD = 0 and SYSREF_DDLY_PD = 0?  Refer to section 9.3.2 in the datasheet.

    Beyond the register dump, is there any extra info as far as process you went through?  Tomorrow I should be able to try this in the lab.

    Adriana Calcutt said:
    What is peculiar is that setting the R and/or N dividers for LMK 1 affects the phase noise of LMK2, and vice versa

    Are you currently testing this with 2x LMK04828 EVMs or your own implementation?  There shouldn't be an impact between PLL2 of LMK1 and LMK2.  However R&N changes of PLL1 of LMK1 changes could impact phase noise profile of both PLL1 and PLL2.

    Adriana Calcutt said:
    Also, I seem to be unable to properly read and write from the registers on LMK1 until I read from register 0x003 first, otherwise I simply get a return value of 0x000 from any register I read/write to.

    This is strange, that you cannot read/write registers on LMK1 until read from reg 0x003.  Looks like you are using 4 wire readback mode.  Are the readback lines shared?

    As for the determinism, your concern is with respect to the 300 MHz clocks, correct?

    73,
    Timothy

  • The two LMKs are programmed as follows:

    • All of the desired initialization values for LMK1 are set

    • Sysref pulse is configured and sync pin is toggled

    • All of the desired initialization values for LMK2 are set

    • Continuous sysref is configured and sync pin is toggled

    The initialization sequence follows the recommended programming sequence from the manual. SYNC_DISX, SYNC_DISSYSREF, DCLKoutX_DDLY_PD, and SYSREF_DDLY_PD are all set to zero on initialization. I refactored the code this morning so that SYSREF_MUX isn't set in the initialization code until after all of the aforementioned registers were set to zero and after the sync pin was toggled. This has not fixed the issue.

    We are currently using our own implementation. I have attached a document of the timing distribution used. As far as I can tell we are programming everything with the appropriate register values. I understand that pll2 of LMK1 should have no bearing on LMK2 but it clearly alters the phase noise during measurements. I am quite confident that I am programming the divider values for pll2 and not pll 1 since altering the R and N dividers for LMK2 also adjusts the phase noise on both, yet sets the correct, calculated frequency.

    We are using 4wire readback mode and the readback lines are shared; the MISO lines are shared across both HMCs and the LMKs.

    Are there any power sequencing issues that could be causing the problem? Or could this behavior be attributed to the SPI readback lines?

    We are currently attempting to achieve a deterministic output for a DEVCLK frequency of 300MHz but the system should be deterministic for any locking frequency.

    Thanks for your help!

    System-Time-Board.pdf

  • If you set SYNC_1SHOT_EN = 1 on both your boards, does that resolve your issue?

    73,
    Timothy
  • Is there a particular order or sequence in which I should enable SYNC_1SHOT_EN?

    I tried programming it to 1 for the entire sequence and if anything it made the determinism worse. The system is at a point now where the determinism of the signal is considerably more stable from boot to boot but is still not fully deterministic. We noticed a significant improvement when we adjusted our power on and register writing sequence. Are there any known sequencing requirements other than the one mentioned in the manual? Is there a recommended power on sequence?

  • Is it possible that this is a thermal issue? The boards were operating at a higher than normal temperature today and when I ran the same tests with the same code as before both LMKs showed deterministic behaviour. I then shut them down and cooled them off and when I tried it again with the same code the determinism was lost. It also appears as though the temperature affected the phase noise.
  • Actually, I think I found the root issue is that you had SYNC_PLL2_DLD = 1 for LMK2.  You also seem to have PLL1 DLD selected?  Probably want PLL2 DLD.

    With SYNC_PLL2_DLD = 1 and using the Normal SYNC, what was happening is that until programming of SYNC_DISX = 1  (specifically for DCLKout8 being used for feedback as relates to PLL2 locking).  The PLL was unlocked and all outputs held in SYNC.  When SYNC_DIS8 = 1, the DCLKout8 was allowed to operate which allowed PLL2 to lock, upon locking, SYNC was removed, and that was the point at which dividers started operating normally (or the programming of SYNC_DISX if all divders were set = 1).  This timing was not deterministic between devices and hence the different alignments.

    With the SYNC_1SHOT_EN SYNC doesn't get held, only the rising edge has significance for resetting dividers.

    Upon looking at this, I think the simple thing to do is not use SYNC_PLL2_DLD... because you need the dividers to be deterministic with respect to the SYSREF divider.  IF you want to use SYNC_PLL2_DLD, which SYNC_1SHOT_EN effectively eliminates use of SYNC_PLL2_DLD, what you could do is after PLL2 is locked.  Use SYSREF Pulser mode or Re-clocked mode to generate a SYNC pulse deterministic to the SYSREF Divider provided that SYSREF Divider and DCLKout8 have deterministic phase.  (Or just use SYSREF Divider for 0-delay feedback instead of DCLKout8).  You may need to adjust the digital delay of the dividers synced relative SYSREF Divider to have exact digital phase relationships.
    --

    As for your question about temperature dependance.  This should not be a factor.  There will always be analog shifts associated with temperature, but it should not cause digital jumps in the PLL in a 0-delay case.


    73,
    Timothy

  • Hi Timothy,

    Thanks for the solution. We wound up turning off SYNC_PLLx_DLD on everything except for pll 1 of LMK 1 and enabling SYNC_1SHOT_EN on both LMKs. So far this seems to have worked and both LMKs appear to be deterministic.

    Thanks again for your help! It is much appreciated.

  • Great.  Note that the root issue was the SYNC_PLLx_DLD.  SYNC_1SHOT_EN should be able to be either value.  With SYNC_1SHOT_EN = 1, you will never allow you to hold your clocks in an off state, but it may be desirable to have known timing with respect to "rising" edge of SYNC vs. "falling" edge.

    Keep your eye open for some app note info soon to be posted related to this topic.


    73,
    Timothy