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

PLLATINUMSIM-SW: Phase Noise Glitch When Loading Oscillator Data

MP
Prodigy 50 points

Part Number: PLLATINUMSIM-SW
Other Parts Discussed in Thread: LMX2594, LMX2820

When I set up a PLL simulation, if I input the reference oscillator phase noise data from a file, the total phase noise shoots up to +24 dBc/Hz at 10 Hz offset.  Is this a software bug?  

Screenshot 2025-11-13a.png

If I type in the oscillator phase noise manually it seems to work (though I think I have seen the same behavior when using the points option):  

Screenshot 2025-11-13b.png

Is there a way you can increase the number of offset points for the reference oscillator?  I need to go out further than 100 kHz offset to reach my reference noise floor.  

Also, at higher offset frequencies, the simulated phase noise seems high.  For intsance, at 10 kHz the simulation shows -109.7 dBc/Hz.  But since this is well within the loop bandwidth, I would exepct it to be closer to -143 dBc/Hz + 20log(2560/160) = -119 dBc/Hz.

Thanks.

 

  • 0
    TI__Mastermind 35500 points

    The +24dBc/Hz at the first point is a bug, yes. We have a fix but it will take a little while to hit the web.

    If you need more points, load a trace, and maybe insert a dummy point at 0.1Hz while we work on the fix.

    Looking at the total noise graph, I see that the VCO noise is heavily dominant at the 10kHz and 100kHz offsets. You also have a large value of C2, which makes for a stable loop filter, but which results in much more VCO noise being let through at lower offsets. As an example, try setting C2 to 82.5nF instead of 825nF, and you'll see that the 10kHz offset comes a lot closer to the expected result (-116.1 dBc/Hz).

    If the VCO is completely eliminated, you will still see greater than -119dBc/Hz by some noteworthy amount. The remaining difference is a result of the 1/f noise contribution from the PLL (and to a small extent, the FOM or flat noise contribution). The figure of merit for 1/f is specified as the phase noise at the 10kHz offset for a 1GHz output, and is correlated noise; so we would expect the 1/f noise contribution to be FOM + 20 log(Fout/1GHz) = -129 + 20 log(2.56) = about -121 dBc/Hz. This is very close to the -119 dBc/Hz offered by your oscillator. Even if we completely eliminated the VCO noise contribution, the resulting phase noise is the sum of the reference and PLL noise, which is 10*log(10^(-119/10)+10^(-121/10)) = -116.9 dBc/Hz. Since the 1/f contribution is independent of reference frequency and N-divider value, as long as you need 2560MHz output, you can expect the LMX2594 PLL to contribute significantly to the total noise at the 10kHz offset (and the 100kHz offset, since -143 to -154 is comparable to the 10dB/decade slope of the 1/f contribution).

    As for the 100kHz offset, this could be made lower by opening up the loop bandwidth. If 100kHz loop bandwidth is an arbitrary decision, I'd suggest opening up the loop bandwidth to more like 400kHz, as this will be closer to the optimal point for trading off between reference/PLL noise contribution and VCO noise contribution.

    You can try to squeeze some more performance out of LMX2594 with a 2nd order loop filter instead of a 3rd order loop filter, as C1 becomes the cap right next to VTUNE and can be a little larger without significant degradation of phase noise or limitation of loop bandwidth (see screenshot below). But if you need better performance at 10kHz or 100kHz offset, you'll need something like LMX2820 (which may not be an option if the LMX2594 space/enhanced variants are required).

  • 0
    Prodigy 50 points

    Thank you for the quick response.  There is a lot of good information in there, and I'm still reading through it to understand it all.  I may have follow-up questions.  

    A quick first question - do you recommend the LMX2820 because it has lower 1/f noise (-134 dBc/Hz vs. -129 dBc/Hz for the LMX2594)?

  • 0 in reply to MP
    TI__Mastermind 35500 points

    If the performance of LMX2594 is satisfactory, the sticker price on LMX2594 at time of writing is about $30 less at 1ku volume, and LMX2594 will dissipate a few hundred mW less power than LMX2820. And there's no space-grade or enhanced-product version of LMX2820 at this time, which may or may not be a factor. The LMX2820 does integrate its output pull-up on-die, which flattens output power across frequency; but for a fixed-frequency use case at 2.56GHz, this may not be a significant concern.

    I ran the numbers and realized that the benefits of LMX2820 might be overstated in your use case. While the 1/f noise is better and mostly out of the way of your reference, we're talking about maybe 1dB improvement over LMX2820. At higher offsets, now the PLL FOM will start to have an impact - this is a noise floor contribution that scales with 20*log(N), and is typically normalized to a 1Hz bandwidth. If Fpd is the same (160MHz) and Fvco is the same (10240MHz), the FOM noise would be the same for both LMX2594 and LMX2820, and would be FOM + 20log(N) + 10log(Fpd) = -236 + 20 * log(10240/160) + 10 * log (160MHz) = -117.8 dBc/Hz at 10240MHz; scaling to 2560MHz, we get -117.8 + 20 * log(2560/10240) = -129.9dBc/Hz in-band noise floor for the 2560MHz output. For a loop bandwidth close to or greater than 100kHz, now the PLL noise floor is comparable to the reference at the 100kHz offsets - and unlike the 1/f noise, the floor is flat across bandwidth (or might even have some slight peaking), so there is no longer any benefit from increasing the loop bandwidth. Both LMX2594 and LMX2820 allow for a 320MHz phase detector in integer mode (at the cost of about 1dB increase in 1/f contribution due to the added 1/f noise of the reference doubler), which can push the 100kHz offset down by about 3dB. This intuitively makes some sense: double the phase detector, and we cut N in half (6dB improvement), but we also double the amount of charge pump noise injected into the loop (3dB degradation) for a net 3dB improvement. But as mentioned that would come at the cost of 1dB degradation at the 10kHz offset, and increasing the loop bandwidth pushes more of the VCO noise into the 1MHz offset, which we haven't considered up to now. 

    I get the impression that this is starting to get overwhelming, so let's take a step back and clarify objectives:

    • Do you have some phase noise mask or budget you must hit?
    • If this is more of a "do the best we can" scenario, what constitutes "better"? For example, are there offsets that are better to optimize (e.g. prefer 10kHz over 100kHz)?
  • 0 in reply to Derek Payne
    Prodigy 50 points

    Thanks again.

    I'm not sure I can share our phase noise spec, but it is given really close-in (on the order of 100's of Hz).  So, I think the noise is going to be determined by the reference and PLL noise, regardless of the loop bandwidth.  We also have a floor spec for offsets > 100 kHz.  

    We know we are going to have a tough time meeting the phase noise spec, given our reference oscillator.  The task was to see what noise we get using the integrated PLL, and then see if other improvements can be made at a system level to bring the noise down.

  • 0 in reply to MP
    TI__Mastermind 35500 points

    If the close-in noise is the part you care about, then in an optimal configuration, I think LMX2820 by itself would buy you maybe 1dB in the 1kHz to 10kHz offsets, and 2-3dB in the >10kHz to 100kHz offsets, compared to LMX2594. I think neither device is going to significantly impact offsets from 1Hz to 1kHz - that will all be reference noise. All that said, I think the general shape of the simulation I posted earlier is close to what you can expect from either device.

  • 0 in reply to Derek Payne
    Prodigy 50 points

    "If you need more points, load a trace, and maybe insert a dummy point at 0.1Hz while we work on the fix."

    I tried this with my oscillator phase noise file by inserting a point at 0.1 Hz in the file.  I still have the same issue.  When you say load the trace and then insert the dummy point, do you mean insert the point in PLLatinumSim after loading the data?   How would you do this?  Or is there another workaround that might work?

    Thanks.

  • 0 in reply to MP
    TI__Mastermind 35500 points

    In retrospect, that was bad advice - the problem was that the first point of ANY trace was being set to 0dBc (before output frequency scaling), so there was no chance that would fix the problem. My mistake.

    In any case, I pushed PLLatinum Sim v1.6.9.1 to the web today (https://www.ti.com/tool/download/PLLATINUMSIM-SW) which should fix the problem.