• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 21 subscribers
  • Views 935 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.

LMX2594: Phase shift

Reno
Prodigy 60 points
Part Number: LMX2594
Other Parts Discussed in Thread: LMX2820, LMX2572

Dear,

I would have a question regarding phase shifting between two LMX2594. I have a custom board and a custom program which imports the register file generated by the "TICS Pro" software. After the register map is loaded only the needed registers are modified(Currently only the MASH_SEED).

after the registers are loaded to both LMX boards I can get a phase sync. The problem starts after I want to phase shift the signals since the actual phase shift is quasy random

For example, below are the calculated values for both boards. After I write the registers I get a lock and phase sync at 500MHz.

From the configuration each MASH_SEED step should generate a shift of PH=360*4/(6*16)=15degree. If I write even multiple times the same value the phase will change.

the registers for the phase shift are changed as followed:
1. write register 40
2. write register 41
3. Write register 44 with MASH_RESET_N=0
4. Write register 44 with MASH_RESET_N=1

Have I missed something?

  • 0
    TI__Mastermind 33790 points

    Hi Ram,

    The MASH_SEED is an accumulator: each time you write to the MASH_SEED, the new register value is added to the previous accumulator value. So once you have the devices synchronized, you should only need to write to the MASH_SEED with the new phase increment, no MASH_RESET_N is needed. MASH_RESET_N will reset the MASH_SEED asynchronously, which could impact the synchronization you already achieved.

    So, for instance, if you wanted to make two 500MHz signals at 90° offset, you would:

    • Follow the sync procedure you're already following to get phase sync
    • Pick one of the devices, and write MASH_SEED = 6 (you only have to write the LSBs for this case)

    After that, the phase offset should be established.

    Regards,

    Derek Payne

  • 0 in reply to Derek Payne
    Prodigy 60 points

    Dear Derek,

    thank you for the quick response. I have now tried two scenarios, with VCO_PHASE_SYNC enabled and disabled. Your suggestion regarding MASH_RESET_N (its constantly 1 and not anymore toggled) helped and I get now a phase shift which matches the equations when VCO_PHASE_SYNC = 0.

    However, the problem is not solved when VCO_PHASE_SYNC = 1. Looking to an other post I have found an answer that says that IncludedDivide is not considered part of the PLL_N value. So just to make sure that I understand correctly; if VCO_PHASE_SYNC = 1 means that IncludedDivide != 1 and there is no guarantee that any desired phase could be set?

    To understand my problem better. I have a signal which is generated by board1 and delayed (the phase shift is known). Board2 has to generate a signal which has a phase offset of 180 degree(so phase offset + 180degree), or as close as possible to the original signal. To find a solution for my problem VCO_PHASE_SYNC could be also 0, but is there some way to determine the phase offset between the two boards itself after a lock (in case that vco phase sync is not used)? Or maybe there is some way that the phase difference remains the same for each frequency? Now after I have switched back and forth between two frequencies the phase offset has always changed.

    thank you, regards Ram

  • +1 in reply to Reno
    TI__Mastermind 33790 points

    Ram,

    As Dean mentioned in the linked post, there are clearly cases where the phase SYNC does not behave as expected, and we don't have a good grasp on which cases are affected. It would be self-defeating if VCO_PHASE_SYNC=1 (which is required for SYNC mode) prevented reproducible phase offsets, and there are definitely cases where everything works correctly. I am not sure exactly what the trouble is, but it sounds like something in the included divide is not being reset properly in some cases. There isn't much I can add to the linked post description of the problem; it is persistent and troublesome. We have a few other devices such as LMX2572 and LMX2820 which purport to have fixed these strange issues with phase SYNC and included divide, mostly by eliminating the concept of included divide.

    As far as mechanisms to detect the phase offset, the only thing I could think of is to use external circuitry to determine if the two outputs constructively or destructively interfere when combined in some way.

    Regards,

    Derek Payne