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.

LMK1C1108: LMK1C1108PW problem with static input (instead of clock).

Part Number: LMK1C1108

For some reason, in my circuit LMK1C1108 is not working with static input (input = HIGH).

  1. It works fine with a 20MHz clock input (ASCLK1).
  2. The output doesn't always rise from LOW to HIGH when there is a step input (ASDI1).

In some cases, the output goes HIGH after an additional attempt (the input goes LOW and is set back HIGH).

  1. On the one hand, the DS shows a logic-level table and it looks like static input should be supported.
  2. On the other hand, the DS specifies the output enable/disable time in cycles of the input signal, meaning that the input can't be static.

  • The LMK1C1108 is a synchronous clock buffer, implying it has several synchronous stages between the input and the output. There is actually a three-cycle initial delay for the internal states of the latches to be effected before the device truly begins behaving as a buffer. Likewise, the enable/disable triggers have to be clocked by the input clock before they can take effect.

    If you first drive a handful of high/low transitions at ASDI1 to set the internal latch states, henceforth it should behave as expected even with static input. I can't remember exactly how many cycles are required, or if the quantity is unchanged between power cycles, but 5 cycles (as implied by the 1G input latency) is a reasonable guess.

    This behavior isn't surprising if you think about how a synchronous enable/disable must be implemented, but that's an extremely subtle clue from which to extrapolate the input latency characteristics. I've gone through the datasheet twice, and I don't see us mentioning this anywhere (except obliquely via 1G input latency). This behavior personally confounded some validation efforts during product design, and I had thought we documented this behavior several years ago to be placed in the datasheet as a result of our own troubles with it, but it appears we never made the edit; in any case, I'll check if this is in the datasheet revision queue, and either re-prioritize it or add it as a high-priority item.

  • Thank you.

    Now I'm toggling the ASDI1 line for every conversion cycle and it works.