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: LMX2594 Full assist with Vtune control

Part Number: LMX2594


Hi,

I am using  LMX2594 Vtune control with full assist and the settling time was the same as full assist only – 300uSec. (we are using approximately 10KHz LP )

Is the Vtune option supposed to improve the settling time when using full assist ?

  • Hi Shay,

    With full assist, VCO calibration is skipped and therefore the overall frequency switching time is shorter than no-assist. 

    Please check if the following appnote on calibration can help you.

    www.ti.com/.../snaa336

  • Hi

    I am using full assist with vtune control -  1.25v

    Disable charge pump

    a.       CPG(R14[6:4])=0

    2.       Power up Vtune Driver (needs override bit)

    a.       VTUNEDRV_OVRD(R8[10])=1

    b.      VCO_VTUNEDRV_PD(R19[13])=0

    Than i am using full assist and set the cap, daci and vco that i got from the readback

    And finally I set

    VCO_VTUNEDRV_PD(R19[13])=1

    VTUNEDRV_OVRD(R8[10])=0

    CPG(R14[6:4])=1

    Unfortunately this mode didn't get better settling time than only full assist mode .

    Do the Vtune mode 1.25v suppose to improve settling time in full assist mode?

    Best regards

    Shay

  • Hi Shay,

    I see what you did but I don't think this Vtune driver approach can help reduce lock time significantly because you have additional registers to program.

    With full assist, we have bypassed the VCO calibration and so the lock time is basically equal to the programming time + PLL analog lock time. 

    My suggestion is, increase the programming speed. This will reduce the programming time as well as reduce the glitch due to CAPCTRL, DACISET, ... not effective at the same time because of programming sequence. You may also need to modify the loop filter in order to reduce lock time.

  • Hello,

    I tried to expend the lp to 30kHz and not using full assist.

    The simulation lock time results was 300usec - total but I got in lab 800usec settling time.

    Why there is a big different between simulation and reality?

    Thanks

    Shay

  • Hello Shay,

    Can you share your PllatinumSim simulation file? You can save the simulation by going to File->Save Design.

    Also what is your SPI programming speed?

    Thanks,

    Vibhu

  • Hi ,

    I tried to upload the file but there was a problem in web .

    If you want I can send it to the mail.

    I just did another test in lab 

    the LP circuit :

    C1 = 2.2nF

    C2 = 68nF 

    C3 = 1.8nF

    R2 = 120 ohm

    R3 = 180 ohm

    Fosc = 100MHz

    Fpd = 10MHz

    I set the LMX2594 in Frac mode to 4800MHz and the send only the controls below 

    240402

    2B0014

    002414

    00241C

    and the settling time from the last digital word was 800uSec ( not including digital word  - only PLL settling time)

    I am using SPI with 20MHz clk .

    The simulation program show 205uSec - Total lock time .

    Thanks

    Shay

  • Hello Shay,

    Can you share your register file? Particularly we are looking for your R0, R1, R4, R19, R20,  R60, R78.

    These registers contain delays w.r.t. the calibration procedure. What frequency are you starting at before the calibration procedure.

    Thanks,

    Vibhu

  • Hi,

    The register :

    R0 = 00241C

    R1 = 010808

    R4= 040A43

    R19=1327B7

    R20=14E048

    R60=3C0000

    R78=4E0003

    Thanks

    Shay

  • Hi Shay,

    your R36 = 0x240402, that means PLL N = 1026. What is your phase detector frequency?

  • Hi

    The Fpd is 2.5MHz

    Thanks

    Shay

  • Hi Shay,

    2.5MHz x 1026 = 2565MHz, this is not a valid VCO frequency.

    could you use TICS Pro to generate your configuration?

    You can upload the .tcs file with the "Insert File" button above in the menu bar (the paper clip icon)

    If you are able to capture a frequency vs time plot will be great for debug, this will give us visual to understand which parameter is creating long switching time.