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.

  • TI Thinks Resolved

LMK04828: Phase Noise Issue

Prodigy 120 points

Replies: 10

Views: 204

Part Number: LMK04828

We have a board with two FPGAs and four LMK04828s. Each FPGA programs two of the LMK04828s. However, each of the four LMK04828s share the same oscillator reference which is fanned out using a low jitter LVDS buffer. The two LMK04828s programmed by the first FPGA appear to have acceptable phase noise performance compared to the baseline taken using the evaluation board. However, the other two LMK04828s connected to the second FPGA have terrible phase noise under 100k offset and the charge pump output pin appears to have a sawtooth-like waveform. The first two LMK04828s are identical in schematic design to the second set of LMK04828s and their layouts are very similar, but not 100% the same. I do not understand what could possibly be going on with the second set connected to FPGA 2. They are like this on all boards so its not just a one-off issue. I am including screenshots of the eval board basline which has about 287fs of jitter, an output of one of the second LMK04828 on the first FPGA & its CPout value, and an output of the second LMK04828 on the second FPGA & its CPout value. Also included screenshots of part of the schematic showing the output used to connect to the E5052A. This output has 240 ohm bias resistors since the output is LVPECL. Also shown is a schematic showing the clock reference and fanout buffer. 

  • Kevin,

    OK, so it sounds like the same input refernece and similar setup, but the difference being the programming by the FPGA's.
    Assuming you are programming the same thing, perhaps it has something to do with the timing or write speed of this programming.

    These device have a VCO calibration that finds the optimal internal settings for the VCO. However, if this calibration is done before the LDOs on the device are stable (from cold power-up) or before the input refernece is stable, the VCO calibration could come back with poor results

    Two considerations:
    1. When you program the synthesizers, are you sure that the LDOs and input reference are stable at that time?
    2. Have you tried a double-write to see if it makes the problem go away? If so, it indicates a timing issue.

    Regards,
    Dean
  • In reply to Dean Banerjee:

    1. The board is already powered on for minutes before we even program the FPGAs so the LDO would already be stable (we are manually programming FPGAs with Vivado at this point).
    2. Have not tried a double write, however we are in the process of reading back register values to verify that everything written to the LMK matches what is read back. So far its good. The programming speed of the SPI clock is around 2.5MHz.

    3. i should also note that the two LMKs that are not working correctly do report that PLL2 is locked (be reading the register value) which is odd because with that much variation on CPout and the phase nose on the output, I do not see how it could be locked. 

  • In reply to kevin priest:

    Kevin,

    This VCO requires calibration, which is internal to the device and triggered by the action of programming the 0x168 register to any value. This calibration searches through a large number of frequency bands and determines the correct frequency band and amplitude;  this is all internal to the device.   For this calibration to be valid, the internal LDOs of the device need to be stable and PLL1 needs to be locked.  Although the supply is stable, I don't know if the default power on reset state for all internal LDOS is powered up or not;  it's not the case for many of our other devices.  The other thing would be if the VCO calibration runs before PLL1 is locked.  In this case, it could calibrate to the wrong frequency band and get stuck there.  Note that when you read the regsiters back, you get the same results whether the calibration is successful or not.

    To test this theory, wait at least 10 ms and then program register 0x168 one more time to the same value to re-activate the VCO calibration for the PLLs with the problem.  If this fixes your problem, then points to the timing of the writing to the device.  If not, it's something else.

    Regards,
    Dean

  • In reply to Dean Banerjee:

    Dean,
    We are using a single loop 0-delay setup so PLL1 is powered down. We are only using PLL2 and we are feeding our reference into OSCin pins as shown in the schematic image I included in the post. So in this case, does what you saying still apply to PLL2? I will try what you are suggesting with register 0x168.
  • In reply to kevin priest:

    Kevin,

    In this case, instead of PLL1 locked, this would mean that you would need to be sure that you are programming 0x168 after your input reference is stable. In any case, programming register 0x168 will quickly prove or disprove this theory.

    Regards,
    Dean
  • In reply to Dean Banerjee:

    if we write 0x0F into 0x168 nothing happens. At least nothing we can detect on the signal source analyzer. If we write 0x00 to 0x168 we get a different profile (shown below), however the output clock is about 297MHz and PLL2 is not locked. If we then write 0x0F back to 0x168 at this point, the PLL locks and the phase noise plot goes back to looking all distorted again. We noticed DAC LOCKED register is always low - but do not know what this means. I also probed all of the voltage pins on the IC and did not see a difference between the two LMKs that work and the two that do not. The only difference seen on the pins is the jitter on the clock outputs and the the CPout behavior. What could the issue be? If the thermal pad was not soldered down properly could this be the case? Or noise coupled into a particular pin?

  • In reply to kevin priest:

    Kevin,

    When you write register 0x168, write it with whatever value you used last time you programmed it, not 0x0.

    You should get the same spectrum when you do this, but if not it indicates something going on with the VCO Calibration.

    I'm not super familar with this device, but I think that perhaps this is suggesting that PLL1 is not locked.

    Regards
    Dean
  • In reply to Dean Banerjee:

    Dean,
    I think you misunderstood my last post. We did write to 0x168 with the value we first programmed it with which was 0x0F - just as you said to do. However, that did nothing - at least nothing we could detect on the E5052A. So then for fun we programmed in 0x00 just to see if it would respond. As you recall form the earlier post, PLL1 is not being used so no it will not be locked and does not need to be.
  • In reply to kevin priest:

    Kevin,

    Is the hardware, specifically the loop filter the same for both the locking and not locking cases? For the case it does not lock, it does look like maybe the VCO is choosing the correct frequency band, but perhaps there is some sort of instability. Also, this can happen if you accidentally swap the loop filter capacitors in the loop filter.

    Regards
    Dean
  • In reply to Dean Banerjee:

    Hello Kevin,

    Do I understand that you have more than one board with 4x LMK04828s.  On each board the LMK04828s in the specific position of... I'll call them #1, #2, #3, or #4 each have the same behavior between boards?

    Based on your charge pump voltages not being railed, I expect the locking and calibration to be OK.

    The charge pump sawtooth looks as if there is some large leakage pulling the charge pump high or low.  If you tri-state the PLL2 charge pump, are you able to confirm this net is high impedance or if there is some impedance pulling to ground or Vcc?  For this test, set PLL2_CP_TRI = 1.  This is located in register R361, bit 1.

    * Granted, your schematic looks legit for your PLL2 loop filter.

    What is the frequency of your PLL2 phase detector?  Looking at the charge pump waveform, it seems the period is about 570 us resulting in ~1754 Hz PDF rate?

    It seems both plots you shared, the good and the bad both have spurs at this ~1.7 kHz frequency... although I don't see that in the EVM case.  In the 'good' case the spurs are small.  In the 'bad' case the spurs are totally destroying your phase noise.

    > Could you share your programming with me?  Or at least the PLL2_R, PLL2_REF_2X_EN, PLL2_N, and PLL2_P values for starters?  With your 20 MHz reference, I would expect you have PLL2_R = 1 and optionally the doubler enabled for a 40 MHz PDF frequency.

    > One more thing, what is the state of pin 6, SYNC/SYSREF_REQ?  Is it quite?  Noise can couple from that pin to VCO0, and to a lessor extent VCO1.

    Dean Banerjee
    We noticed DAC LOCKED register is always low - but do not know what this means.

    When PLL1 is being used an TRACKING is being used for Holdover, DAC LOCKED means the proper holdover voltage which will be applied by a DAC will be minimized based on the current PLL1 Vtune.  Not applicable to your issue.

    73,
    Timothy

    ____________________________________________________________________________________

    To design your own Clock Tree solution, visit WEBENCH Clock Architect​​​​
    More information Clock and Timing System products: http://www.ti.com/clock-and-timing/overview.html

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.