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.

LMH1983: How to synchronize PLL1 in a V/H (without F) system

Part Number: LMH1983

Tool/software:

Hi Sir.


I have a question.

We use LMH1983 in a system where there is no F and only V and H are provided.
We also want to GenLock PLL1 as soon as possible from H.

Since there is no F, we plan to disable AutoFormatDetection at 0x05[5] and change 0x20 manually when the system becomes controllable.

However, I believe that the LMH1983 will start GenLock for PLL1 even before 0x05[5] is disabled and 0x20 is manually specified, based on (1) and (2) below.
Is this correct?
If this is correct, I am thinking of accelerating the power-on timing of the LMH1983, even if the timing of becoming controllable is later.

(1)0x05[4:3] default is set to GenLock mode.
(2)0x11[5:4] default should is set to NeverAlign.

Best regards,

Hiroaki

  • Hi Hiroaki-san,

    Right, after a soft-reset, the device will be in Genlock mode. Since you don't have a F-sync signal, TOF is not possible, we should set 0x11 to NeverAlign.

  • Hi Fung,
    Thank you for your response.
    I would like to ask a few additional questions.
    As before, I would like to have the CLK Out1 output synchronized to H as soon as possible.

    (1) About NO_LOCK signal
    Am I correct in assuming that the NO_LOCK signal will not go Low unless both the primary and secondary loops of PLL1 are Locked?
    In the evaluation board pre-check, NO_LOCK was not output low forever without I2C control in the system without F.
    From your previous response, we believe that NO_LOCK is output high due to the effect of F not being input and the secondary loop (for TOF1) not being locked.
    In other words, I believe that the primary loop (for CLK1 out) may be locked even if NO_LOCK is not output low.
    Is this correct?

    (2) Behavior when Auto Format Detect is disabled by I2C control
    I ask this question on the assumption that the answer to (1) is “Yes” and 27MHz is synchronized to H.
    I think that when 0x05 or 0x20 is changed while synchronized to H, the primary loop will not be unlocked. I also believe that the secondary loop is no longer needed, so the behavior will be that NO_LOCK changes to low output immediately after rewriting 0x05 or 0x20.
    Is this correct?

    Best regards,
    Hiroaki

  • Hi Hiroaki,

    According to the datasheet, my understanding is the NO_LOCK pin will goes LOW as long as PLL1 is locked. PLL1 does not use F, so F will not affect the NO_LOCK pin. 

    To make sure PLL1 locks to H, the H should be low jitter and is a periodic signal. We also need to set LockStepSize and Loss of Lock Threshold properly to account for VCXO vtune voltage variation and missing H pulses.

  • Hi Fung,
    Thank you for your response.

    Your response differs from my understanding.
    Please let me check again.

    In section 8.3.1 of the datasheet, it shows that PLL1 has a primary loop and a secondary loop.
    TOF1 is used for the secondary loop of PLL1.
    Section 8.3.10 of the datasheet states that TOF1 is output when the Fin input is transitioned.
    In other words, F is considered to affect the secondary loop of PLL1.

    If the internal specification is such that NO_LOCK is output low when both the primary and secondary loop are locked, this would be consistent with our evaluation board results and understandable.

    Could you please confirm the internal specification?
    We expect that the internal specification is such that NO_LOCK is affected when both primary and secondary loop lock even if the default of 0x11[5:4] is set to NeverAlign.

    Best regards,
    Hiroaki

  • Hi Hiroaki-san,

    Datasheet Section 8.3.6 told us that the lock state of PLL1 depends on H only. 

    In section 8.3.7, it told us the lock time may depends on TOF1 alignment. If we disable TOF1 alignment (NeverAlign), I expect PLL1 will not have dependency to F anymore.

  • Hi Fung,
    Thank you for your response.

    We understand your response.
    We initially thought the same from the datasheet,
    However, we have obtained the same results in our evaluation using actual equipment as shown in the attached file.
    Could you please confirm this for us?

    Behavior of LMH1983.xlsx


    Perhaps you can understand that the behavior is different from what you answered.

    Could you please confirm the internal specifications by checking the actual device with a prototype board, etc.?

    Best regards,
    Hiroaki

  • Hi Hiroaki,

    this part is not developed by our team, we have very limited capability to pin point the root cause. I will review your information and get back my best guess later this week.