LMX2595: Clock & timing forum

Hi Denny,

I have paged a device expert.

Best,

Evan Su

Hi Denny,

Was your calibration done at room temperature? Were you using the same data for all parts or each part has its own set of calibration data?

We calibrate over temperature and uniquely for each part. The read back of the registers Capcode and DACISET occurs after lock detect. The capcode calibration is currently being done as "No Assist". 

We have confirmed that the capcodes change monotonically with frequency within a VCO core but haven't done so 100%, that will be one of our next steps.

We are considering confirming that the capcode is centered in value by verifying the PLL will lock 5 capcodes above and below the capcode value from the calibration routine. That looks like it would typically cover about 1/2 the tuning range of 0 to 2.5V, assuming the capcode was chosen for 1.25V nominal Vtune.  

How much pulling does the DACISET cause?

Hi Denny,

A capcode represents a few MHz, so it is normal that you may not get very consistent capcode value for each calibration.

After a calibration, Vtune will be around 1.25V. When temperature changes, Vtune will also change. Usable Vtune range is between 0.5V and 2V. 

DACISET will not cause unlock but may affect phase noise and output power. 

Was your test cold-start-up at -40C and then you applied the calibration data which was taken at -40C, you observed that after programming, the device did not lock until a few seconds later it resumed to lock? If this is the case, was your calibration data taken also with a cold-start-up? I am guessing that it takes a few seconds for the device to heat up to match the calibration data that was not taken with a cold-start-up. 

There was plenty of time for the unit to stabilize in temperature for both measurement and calibration. Retaking the measurement gives the same result. The measurement is very repeatable for a given frequency transition. 

The effect is that most frequencies lock in 5-8 usec to +/-200 KHz or better and some take >20 usec. 

Hi Denny,

Does this problem happen at a particular VCO core only?

BTW, is the temperature referred to ambient or board?

We have seen it in VCO cores 2-4 but mostly 4.

The -40C is the housing temperature, the board temperature is 5-10C higher. A nearby FPGA measures 15C higher with its internal temperature sensor but it dissipates power too. 

Does the fully assist cal do frequency 1st (capcode) and then DACISET?

Back to an earlier question, how much pulling does DACISET cause? 

Has this been verified at cold temperature?

Would we be better off if we did a No Assist and then immediately follow by a Close Frequency Assist? It is a much bigger problem at cold, settling times at room and above are much better behaved. 

Hi Denny,

Calibration will perform VCO_SEL, then CAPCODE followed by DACISET.

I looked into the DACISET, it is possible that if DACISET is not correct, Vtune voltage may change by more than 100mV. This amount of Vtune voltage becomes critical at cold temperature. 

What is your DACISET values after calibration? 

At room temperature, it should around the following values at each VCO core.

VCO1   256

VCO2   280

VCO3   257

VCO4   290

VCO5   162

VCO6   188

VCO7   260

Could you also try to change the programming sequence, program DACISET first, then followed by other necessary registers? This will reduce the overall switching time. 

Could you also identify if the problem is not due to the settling time of the loop filter?

We have found the problem goes away when we do a Close Assist Calibration (FCAL_EN=1) instead of a No Assist Calibration to get the Full Assist values, provided the frequencies are in the same VCO core. The suspicion is that when we don't do a Close Assist, the DACISET step pulls the frequency too much, Vtune is too close to ground and that causes the settling to be slow.  

Question: if we are specifying a Close Assist, when does the calibration decide to switch VCO cores? If we started at 7500 MHz and stepped up, when it came to 8600 MHz (boundary of VCO1 and VCO2), would it pick VCO1 or VCO2 as the core?

What is the algorithm the Close Assist uses for picking cores (when does it switch cores)?

Denny,

Close assist works in a similar way as No assist with the exception that the starting values for the calibration chosen are whatever was for the last frequency the VCO was calibrated to.  If you are switching up to a frequency that is at the boundary of two cores, it would first try the existing core that was used for teh last frequency lock.  If this was valid, it would choose that one.  If not, it would go to the next one.

You said that the VCO is undershooting by 12 us for about 4-6 us.  I can think of two reasons why this might be:

1.  Perhaps the VCO is still calibrating.  When the VCO is calibrating, it internally hooks up the VCO to an internal tuning voltage and disconnects it from the loop filter.  12 MHz is still within about one tuning band of the VCO.

2. If the VCO is not calibrating, then perhaps Phase Detector is going in the wrong direction

So what I would do is look purely at the VCOCAL lock detect.  If this 4-6 us is happening during the VCO calibration, then the lock detect should still be low and the tuning voltage should not be railing during this time.  Note that this is a negative tuning coefficient VCO, so if it is railing 12 MHz low, it would be slammed against the upper rail of about 2.5 V.  If you find out that the VCO is still calibrating during this time you see this 4-6 us event, then one remedy woudl be related to the VCO calibration settins, such as using close assist.

Now if this VCO is done calibrating and you see the tuning votlage being slammed to a rail (0 V or 2.5 V), then this could be some kind issue with the PFD going in the wrong direction (i.e. it interprets 1 degree phase error as -359 degrees).  In this case, the 4-6 us time would be impacted by the phase detector and also the loop filter.

Regards,

Dean