• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 4 answers
  • Subscribers 34 subscribers
  • Views 1751 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

LMH1983: Question about LockStepSize

LMH1983: Question about LockStepSize and Loss of Lock Threshold

Mochi
Genius 4165 points
Part Number: LMH1983

Hello Nasser,

Here is related question of LMH1983 Lock detection scheme.

Our customer's product got filed issue, it has Pin11 No_Lock = H behavior even inputted very clean signal, PLL is always Locked.

They had found workaround that is increasing the value of Loss of Lock Threshold (Register 0x1C). However we could reach theoretical mechanism of this workaround effectiveness.

Could you read following little bit longer message, we thank for your help in advance.

  

<< LockStepSize setting >>

On datasheet page16, section 8.3.6:

...LockStepSize (Register 0x2D) and Loss of Lock Threshold (Register

0x1C). The LockStepSize register sets the amount of variation that is permitted on the VC_LPF pin while still

considering the device to be locked....

       Qestion1: Could you elaborate Threshold of actual number of plus count at VC_LPF pin outputted pulse detect to?

On datasheet page31, Register Map of 0x2D:

4:0 Lock Step Size R/W 01000  See Application Information section discussion on Lock Detect

        Question 2: Where is the location of "Lock Detect discussion" in the link of "Application Information"?

        We could not find additional information in datasheet. Is there another document?

 

<< Lock Threshold setting>>

On datasheet page16, section 8.3.6:

The second register, the Loss of Lock Threshold register, controls the lock state declaration of PLL1. This register sets a number of cycles on the HIN input that must be seen before loss of lock is declared. For some reference signals, there can be several missing HIN pulses during vertical refresh. Therefore, it is suggested that this register be loaded with a value greater than six (Loss of Lock Threshold > 6).

On one datasheet page30, Register Map of 0x1C:

0x1C Loss of Lock Threshold

Sets the number of Hsync periods to wait before setting loss of lock. Since during blanking there can have up to 5 missing Hsync pulses, this value is usually set > 6.

 

In your previous e2e reply:

What the datasheet is explaining is that to make the LOCK determination time the fastest, you load LOCK STEP_SIZE with a 1 (minimum amount of time to look at pulses) and LOCK_THRESHOLD with a 31 which is a large number, indicating that even if there is significant activity, the device should declare LOCK.

 

        Question 3: Are those statement saying same behavior?  Following your e2e description, our understanding is that the value of "Loss of Lock Threshold" is time domain window of pulse count measurement at the VC_LPF pin. Unit of time window is Hsync periods. Is that correct? Then what is the relation between the statement of "Sets the number of Hsync periods to wait before setting loss of lock." on the datasheet?

It seems value of "Loss of Lock Threshold" is just Waiting time to set Loss of Lock register after detected certain number of plus at VC_LPF pin. There looks no function of plus measurement "time window". Would you please summarize those three descriptions and re-describe "Loss of Lock Threshold" function in simple words?

Regards,

Mochizuki

  • 0
    TI__Genius 9920 points
    Our expert will reply to you soon.
  • 0
    TI__Mastermind 32575 points

    Hello,

    For the PLL1 lock detector, LOCK1_Threshold is the primary control (lock window size) while LockStepSize is more like a secondary control (window step size).  Here are more details:

    The PLL1 lock detector compares the two PLL1 PFD inputs, PLL Ref clock edge (Hin / R_div) and PLL Feedback clock edge (VCXOin / N_div).  If 3 consecutive edges are within the lock detection window, it declares PLL1 is locked.  If 3 consecutive edges are outside the lock detection window, it declares PLL1 is unlocked.

    The Lock Detect Window sets the allowable clock phase difference between PLL1 PFD inputs.

    • Lock Detect Window (ns) = LOCK1_Threshold * X
      • Default Lock Window = 8 ns because LOCK1_Threshold = 16d and X = 0.5 ns (since LockStepSize = 8).
    • LOCK1_Threshold register (range: 0 to 31d, 32 steps, X ns/step) sets the lock detect window.
    • LockStepSize register (range: 0 to 15d) adjusts the ns/step size (X).
      • X = (0.5 ns * 8) / LockStepSize
      • When LockStepSize = 8 (default), then X = 0.5 ns/step (nominal).

    Examples:

    • For Fast lock detector assert time (= relaxed frequency accuracy = Largest window size), set LOCK1_Threshold = Max (31d) , LockStepSize = Min (0).
    • For Slow lock detector assert time (= strict frequency accuracy = Smallest window size), set LOCK1_Threshold = Min (0), LockStepSize = Max (15d).

    Regards,
    Alan

  • 0 in reply to Alan O
    Genius 4165 points

    Hi Alan,

    Thank you for your reply.

     

    We made some timing chart as attached in NTSC format.

    There is our understanding of LOCK detection of 3 consecutive edges at PFD output. Could you verify this pattern?

     

    Regards,

    Mochizuki

  • 0 in reply to Mochi
    TI__Mastermind 32575 points

    Mochizuki-san,

    One correction: FB Clock needs to be outside the lock detect window (e.g. 8 ns) for 3 consecutive cycles before the NO LOCK status is asserted.

    Regards,
    Alan

  • 0 in reply to Alan O
    Genius 4165 points

    Hello Alan-san,

    We appreciate your prompt comment.

    Then how is below drawing?

    Regards,

    Mochizuki

  • 0 in reply to Mochi
    TI__Mastermind 32575 points
    It looks good!

    Regards,
    Alan
  • 0 in reply to Alan O
    Genius 4165 points

    Hello Alan-san,

    Our customer did additional experiment at following condition.

    Original setting

    LossOfLockThreshold = 16

    LockStepSize        = 8

    Calculated window size = 8nsec

     

    Modified for larger window size to relax accuracy.

    LossOfLockThreshold = 16

    LockStepSize       = 1

    Calculated window size = 64nsec

     

    Our verification result was increased "No Lock" flag at same reference clock input environment, it is opposite of our expectation.

    What do you see the reason of this phenomenon?

     

     

    One more question, As you showed examples like below:

    >For Fast lock detector assert time (= relaxed frequency accuracy = Largest window size), set LOCK1_Threshold = Max (31d) ,

    >LockStepSize = Min (0).

    If we set ”0” for LockStepSize, then Calculated window size become infinity.

    Is Lock detection function still worked with no time limit window at this setting?

     

    Regards,

    Mochizuki

  • 0 in reply to Mochi
    TI__Mastermind 32575 points

    It is better to use LOCK1_Threshold as the primary control for the lock detect window.  LockStepSize is a secondary control and is better to leave near the default value and avoid extreme register values (like 0 or 1).  Do you see the NO_LOCK flag time decrease with LOCK1_Threshold = 31d (max) and LockStepSize = 8d (default), when compared to LOCK1_Threshold = 16d (default)?  Then, try decreasing LockStepSize to 7 or 6 to see if NO_LOCK time can decrease any further.

    Regards,
    Alan

  • 0 in reply to Alan O
    Genius 4165 points

    Hi Alan-san,

    Our customer has been proceeded verification of LockStepSize functionality by changing register value.

    To see enough countermeasure effect of pre-matured No-Lock flag issue, we were using following register setting caused by existing reference clock quality.

    Reduced number of value of LossOfLockThreshold to have enough occurrence of No-Lock flag at LockStepSize = 8, It was LossOfLockThreshold = 2

    Then we are reducing LockStepSize value from 8, resulted in smaller LockStepSize setting correspond lower occurrence of No-Lock flag.

    Except set value 1 for LockStepSize.

    This result showed completely follow your theory, thank you very much for your Patience.

    Here is summary of optimization method of LockDetectWindow(ns) size.

    LockDetectWindow(ns) = LossOfLockThreshold * X

    X = (0.5ns * 8) / LockStepSize

    LossOfLockThreshold register (range: 0 to 31d, 32 steps)

    LockStepSize register (range: 2 to 15d, 32 steps, 0 and 1 are not usable range)

    No-Lock flag is asserted by 3 consecutive cycles of "no lock" condition at outside of the LockDetectWindow(ns)

    *******************************************************************************************************************************

    Finally, let go back to LMH1983 datasheet description.

    There are some discrepancy and might be make customer confusion, could you please clean up those information.

    Page16: LockStepSize should be second priolity and LockThreshold cannot change number of cycles directrly.

    Page17: Is LockStepSize 0x1 setting usable range?


     

    Page30: LockThreshold cannot change number of cycles directly.


     


    Page31: No link of Application information.


    Regards,

    Mochizuki

     

  • 0 in reply to Mochi
    TI__Mastermind 32575 points
    Mochizuki-san,

    Thank you for confirming their positive verification result and for the datasheet feedback.

    Regards,
    Alan