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.

LMK04616: Alternate DEVICE CLOCK and SYSREF distributed across multiple LMK04616

Part Number: LMK04616

Hi,

I am considering using two LMK04616 to distribute DCLK and SYSREF in an alternate manner in order to avoid as much trace crossing as possible. The SNAU22 document of multi-device synchronization does not address this configuration. I am wondering what could be the consequence of this? Again the reason I am want to configure the devices to distribute the required clock for a subclass 1 JESD204B converters, is so that I can keep the DEVICE CLOCK and SYSREF together. This will ultimately avoid any possible crossing that can increase the skew between the traces of these clocks. 

Looking forward to some insight about my question.

Kind regards,

Gianfranco

  • Hello Gianfranco,

    The output channel structure of the LMK04616 requires a channel pair to be either both device clocks or both SYSREF. Consider alternating DCLK and SYSREF across channel pairs, which should still keep the DCLK/SYSREF channels close together.

    Given that each output channel has individually adjustable analog and digital delay controls which can be used to align the skew of the outputs, added skew due to layout should not be too much of a concern. I recommend making routing decisions that minimize routing complexity, then using the analog and digital delay corrections to align the clocks.

    Regards,

  • Hello Derek,

    Thank for taking the time to help me. Yes, I know that the channels are paired and my design with the LMK04616 is designed using the paired output with alternating DCLK and SYSREF. This configuration minimizes trace crossing of these and keeps the signals together. I am also aware that LMK has digital delays to adjust the skew if required. My question is if I configured two LMK04616 to distribute alternating DCLK and SYSREF are there any synchronization issues that I can expect. Since the alternating DCLK and SYSREF across two LMK04616 are not discussed in the datasheet or SNAU222. Trying to rationalise why this is. 

    One possible issue why it is not discussed in for mentioned documents, could be due to the two PLL's that need to be synced perfectly would require an input sync being handled synchronously. Since the in the block diagram of the PLL the sync events are syncrhonized to the prescalled PLL2 output. Ensuring perfect syncrhonization across both divices would be difficult, since 1ns delta could occur causing intermittent failures accross tthe clock signals.  

    Can this be an issues? In a nutshell, if I use two LMK04616 to distribute alternating DCLK and SYSREF(better for routing) can I expect syncrhonization issues between the devices that can lead to intermiitent failures accross the clock signals outputs?  The sync signal would be provided through a FPGA and the VCXO is buffered to both devices to make their clock input path more symmetrical. 

  • My question was whether I would get any synchronization isseus if I configure the devices distributing alternating DCLK and SYSREF across two LMK04616.

  • Hi Gianfranco,

    I understand now, thanks for the clarification. What you are describing sounds similar to case 1C, but with a SYNC signal sent to two different LMK04616 devices at the same time like in case 2. As discussed in SNAU222, the asynchronous SYNC signal is reclocked to the VCO prescaler output, so like in case 2, SYSREF request timing will have uncertainty equal to one prescaler clock cycle. If the period of the DCLK and SYSREF signals is long compared to the VCO prescaler output period, the SYSREF request uncertainty should be negligible, since it should not prevent the SYSREF from remaining aligned to the DCLK signals. In other words, if the SYSREF signal can be shifted ±1 prescaler cycle in either direction without violating SYSREF setup and hold time requirements, the SYSREF request uncertainty should be negligible.

    Regards,