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: Lock Time Measurement Setup

Part Number: LMX2594


Hello TI Family,

We are currently working on LMX2594 Lock Time. We are using LMX2594EVM + Reference PRO. We set up the measurement setup as shown in the EVM. We chose our clock as LVDS 212.5 MHz in the Reference Pro. 

We made Transient Analysis Measurement on the "FSWP" We measured 150 us at "No Assist Mode" and 110 us at "Full Asist Mode". We saw improvement No Assist Mode to Full Asist Mode but this time seemed a little long to us. 50 us is given by the datasheet so looks like there is an additional 100 us between our measurement and the datasheet. Our measurement method may differ from yours. Could you please give us some additional information about your measurement. How you triggered your setup for transient analysis measurement? Our setup was triggered by RF Power. How should we measure exact lock time? Also, we studied your "snaa336a" app note which is about the "Streamline RF Synthesizer VCO Calibration and Optimize PLL Lock Time" but we could not find any information about the setup. Our measurements is slightly similar in the app note. We can share our measurement result if you need. 

Thanks in advance.

Best Regards,

Gozkul

  • Hello Gozkul,

    Due to the holidays, please expect a delay in our response.

  • I'm not sure exactly what's going on, but I do have a few thoughts:

    • You mention using a 212.5MHz reference. Technically this means the CAL_CLK_DIV, the calibration clock divider, needs to be set to divide-by-2 to bring the calibration clock frequency in range. So if you're using the device according to the CAL_CLK_DIV datasheet limits, you should expect almost double the calibration time since the state machine clock is running about half as fast as the example. For experiment only you could try running CAL_CLK_DIV set to divide-by-1 instead, since you're close to the 200MHz limit; this might bring your results more in-line with ours. But I don't think this is the whole explanation, since full assist lock times are usually on the order of a few microseconds, and only marginally involve the calibration clock (it's more of a state machine clock in full assist mode).
    • Just to be sure, you're not programming R0 for full assist calibration, right? The whole point of full assist mode is to skip the calibration, so if you are running the calibration anyway this could add time.
    • The lock time for full assist mode is greatly dependent on SPI frequency and total programming time. We actually hard-coded our full assist conditions into a pattern generator to get a consistent 75MHz SPI with minimal dead time between register writes. If your SPI isn't running as fast as possible, you are greatly limiting the capabilities of full assist mode.
    • Of course, the loop filter also plays a significant role. PLLatinum Sim software can be used to estimate the lock time for a given loop filter, and can find optimal loop filters for a required lock time. EVM defaults are typically optimized for phase noise performance, and may need to be adjusted for lock time improvements. In practice, the full assist transient is pretty small, so I don't expect this to make a huge difference... but it's worth running the numbers to double-check, at least, that the values you measure are as expected.
    • If you're trying to lock the VCO in the range of 11900 MHz to 12100 MHz, there is a special note in the datasheet:

    We typically triggered our setup using the E5052B external trigger, with a dedicated signal from our pattern generator that triggered measurement when either the R0 register write concluded and calibration began for no/partial assist, or when the SPI programming began for full assist. This omitted any disturbances at the output or the 3.3V rails created by SPI programming, and helped match line lengths between the trigger and the SPI lines from the pattern generator.

    Our lock time measurement in the app note isn't amazingly precise - I think we only measured to when the line stopped adjusting in the frequency axis. Depending on how you qualify your lock time thresholds, this number could be off by a few microseconds, but I certainly wouldn't expect it to be off by a hundred microseconds or more. In the past, I have seen some effects where the fractional divider MASH reset has an effect, so if you have phase sync enabled then this could have some effect on the time between reprogramming the numerator and the output finally settling since the fractional divider would be held in an integer state until the MASH reset condition clears, which could be about 50,000 calibration clock cycles by default. Note that MASH_RST_CNT controls the duration of the reset during conditions where phase sync is enabled, and the total duration of the MASH reset during phase sync conditions needs to be greater than the analog lock time. If you have disabled phase sync, I don't think MASH_RST_CNT applies any more.

    I think we also may have hand-waved away some of the register writes required for full assist. Typically we need to write at least the PLL numerator on top of the other three determinant coefficients, and depending on the total frequency shift, spurs, and other device constraints, we may further need to write a bunch of registers in the R, N, and/or output divider paths. Our app note measured a steady-state condition starting where the PLL was not locked but was relatively stable, and ending where the PLL was locked - implying the dividers were pre-configured. In reality this should add some time to the overall procedure. Again, not a hundred microseconds, but a few microseconds maybe.

    Hopefully this is enough to point you in a useful direction while our other RF specialists are out for the US holidays.