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.

LMK04828BEVM: multi chip configuration initially in-phase right after SYNC pulse, then come out of phase

Part Number: LMK04828BEVM

Hi,

I'm having an issue where I have a two board setup and am probing the same outputs of two LMK04828Bs that are programmed the same way and I'm trying to get these two outputs to have a deterministic phase.

Some notes:

  • same 10MHz reference to each CLK0
  • each LMK04828B has a 160MHz VCXO (separate ICs on each board, but same model producing the 160MHz)
  • each getting 1.8V SYNC pulse on the SYNC input
  • output clocks are:
    • 192 MHz
    • 2 MHz SYSREF
  • nested 0-delay mode with SYSREF as feedback clock

The 192 MHz is key for what we are trying to do, and right now we need to get this to work with a 10MHz reference. The SYSREF frequency is less important. It was just chosen to be in integer submultiple of the 192MHz.

What I do is program the LMKs with the registers from the HexRegisterValues.txt file, and then the two chips expectedly come up with the 192MHz clocks at a fixed phase (typically out of phase, sometimes a full 180deg, but it's possible they're in phase). If I reprogram the chips with the full HexRegisterValues.txt file then the LMKs likely come up with outputs with different phases than prior, but as expected these phases are non-deterministic.

When I do a procedure to apply the SYNC pulse (includes SYSREF_CLR=1, SYNC_DIS*=0, DDLY_PDs=0, normal sync mode, SYNC_1SHOT_EN=0, SYNC_POL=0), what I see on an oscilloscope on the SYNC pulse falling edge is that the 192MHz clocks are in phase right after the sync pulse. However, if I retrigger/recollect on the oscilloscope later, the clocks are again out of phase (and seemingly at the phases prior to the SYNC). We've seemed to narrow this happening to after a few milliseconds.

To confirm this, we've been doing the initial config with HexRegisterValues.txt to get the phases to be near 180deg out of phase, then doing the SYNC pulse (where we trigger and verify they become in phase after SYNC) then capture data later or view it in realtime and see that they've appear to drift to the ~180deg phase difference again

Any idea what could be going on here? Thanks!

  • Hi,

    I would be suggesting to go over the multi-clock sync app note to know more about conditions for 0-delay mode and multi-clock sync approach.

    Here, I can observe the devices are not configuring in fully 0-delay mode and see the non-deterministic phase.

    You can try with the 0-delay mode along with divider reset approach, where set the internal SYNC with SYNC_PLL1_DLD --> 1 (which will generate the SYNC once PLL1 will lock) and keep the sync enable to required channels in reset mode (SYNC_DISx --> 0) to resetting the dividers.

    Thanks!

    Regards,
    Ajeet Pal

  • Thank you for responding. I had read this app note prior to posting. I believe the only thing I had not done prior was set SYNC_PLL1_DLD (and I also tried setting SYNC_PLL2_DLD), and even after trying this I am still getting the same results.

    Attached is my HexRegisterValues.txt file.

    8311.HexRegisterValues.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    R0 (INIT) 0x000090
    R0 0x000010
    R2 0x000200
    R3 0x000306
    R4 0x0004D0
    R5 0x00055B
    R6 0x000600
    R12 0x000C51
    R13 0x000D04
    R256 0x010070
    R257 0x010155
    R258 0x010255
    R259 0x010301
    R260 0x010422
    R261 0x010500
    R262 0x010673
    R263 0x010703
    R264 0x010870
    R265 0x010955
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Below is a Python snippet for applying a sync:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    # set to Normal SYNC
    spi_dev.write_val(0x139, 0)
    # set to re-clocked SYNC
    # spi_dev.write_val(0x139, 1)
    # set SYSREF_CLR (reg 0x143, bit 7)
    spi_dev.write_val(0x143, 0x95)
    # turn off SYNC disable bits
    spi_dev.write_val(0x144, 0)
    print("about to sync...")
    time.sleep(1)
    gpio_lmk_sync.set_value(1)
    time.sleep(0.1)
    gpio_lmk_sync.set_value(0)
    print("sync performed")
    time.sleep(0.1)
    # turn on SYNC disable bits
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hi,

    The hex register config file looks good, except can further increase the PLL2_PFD frequency to 32MHz (to improve the phase noise performance), also need to run the test with below sequence:

    1. Initially, load the config file (LMK04828_e2e_updated.tcs), with program SYNC_PLL1_DLD=1, and SYNC_DIS0, SYNC_DIS2, ..., SYNC_DIS12=0 to enable reset. The SYSREF divider does not need to be reset and SYNC_DISSYSREF will not have an effect, because the SYSREF output is used as the zero-delay feedback which can only have one phase (determined by reference input).

    2. Wait for PLL1 to lock

    3. When PLL1 locks, the output dividers will be released from synchronization simultaneously, ensuring every LMK device sees the reference clock at the same phase.

    4. After PLL1 locks, program SYNC_DIS0, SYNC_DIS2, ..., SYNC_DIS12=1 to prevent SYSREF edges from triggering divider reset again.

    5. Set SYSREF_MUX to continuous.

    Please go over the above sequence and let me know, if you still see the issue.

    Thanks!

    Regards,
    Ajeet Pal

  • Thank you! I think it was having SYNC_DISSYSREF enabled that was preventing the SYNC from occurring.

    Prior to your post I had just got it seemingly working in Dual Loop non-ZMD mode, but with your help it's working in ZMD mode.

  • To add some clarification to this, I'm now noticing that the SYSREF are never synced and out of phase between the two boards. I could get around this by doing two syncs (one first in Dual Loop where SYNC_DISSYSREF=0, then one in Dual Loop ZMD with SYNC_DISSYSREF=1), but if there's another way I'm all ears.

  • Hi,

    May be I am not able to get your point here.

    Are you able to get the synced output or not? can you please elaborate more?

    Thanks!

    Regards,
    Ajeet Pal