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.

LMX2581 - Affect of certain features on Phase Noise Performance

Other Parts Discussed in Thread: LMX2581

Hello,

I am using an evaluation module of the LMX2581 to study the phase noise performance it delivers. CodeLoader is being used to program the LMX2581 and the Agilent E5052B Signal Source Analyzer to observe the noise performance of the generated output.

Since a certain frequency can be achieved with a number of different combinations of parameters, I'm looking at what combination would give me the best noise performance. And based on this, generalize on what would be the best approach for a wide range of frequencies.

My questions are as follows:

1.  The datasheet mentions that not using a shunt cap of around 3.3nF would degrade VCO phase noise performance ( Figure 17 in section 8.3.7 of the datasheet). However, even upon using a 330pF shunt cap I cannot observe any such degradation by simulating the VCO phase noise using the clock design tool. Why is that? 

2. CPG Bleed - The datasheet doesn't mention what exactly this parameter controls. Also, it advises users to set it to 0 when using the device in Integer Mode. Moreover, it only specifies using settings of either 0, 2 or 4 across all scenarios. However, when I set the CPG Bleed word to 15, I'm observing significantly better RMS Jitter of 270fs compared to the RMS Jitter of 340fs when it is at 0 (For a RFoutA of 1100MHz, and integration range of 1kHz to 10MHz) . So, it would be great if someone could provide an explanation of why this occurs and what might be the best way to decide on an optimal CPG Bleed value.

3. OUTA_PWR - The datasheet specifies that the least noise floor is achieved for a setting of 15. At what frequency is this noise floor calculated?  However, I'm observing better RMS Jitter performance (difference of roughly 40fs) when using a setting of 30, with the phase noise at an offset of 10MHz better for for a setting of 30 than 15. 

4. Dithering/Fractional Order: The datasheet recommends that for best phase noise and spurs when the numerator is zero, it is best to disable dithering and set the order as zero. However, yet again I'm observing better RMS Jitter performance (difference of roughly 25fs) when using a second order modulator with strong dithering even when the numerator is zero. I'm clueless as to why this happens.

That is all. I'd be really grateful if someone could answer these queries as I'm very confused as to why I don't observe the same trends/results as those mentioned in the datasheet.  Do let me know if you need any other details and apologies if the questions are a bit trivial. 

Thanks and Regards,
Ajay

  • dear Ajay,

    thank you for your questions:

    1) clock design tool will not simulate second and third order effect. It will provide a very good idea of the performance but will not account for small details such as this one. Using the EVM will produce the final say in performance.

    2)CPG Bleed. this is a technique used to avoid the so called dead region is the CP around the zero point. By constantly forcing a current from the charge pump, it allows the operation point to be away from that dead zone and can help with spur or dithred phase noise.

    3) the table you are reffering to in the D/S for output power (table 7) is an attempt to provide some guidelines on how power will affect noise floor. It is not met to be a must but simply a trend. Each use case might not follow this trend perfectly. I would not be concerned if you find for your use case does not follow the trend exactly.

    4) This is not something I have seen and it does not add up. Are you positve that the device is in integer mode?

    Regards,

    Simon.

  • Dear Simon,

    1) Okay, I shall try that out.

    2) and 3) Thanks for the explanation. But the major issue I have here is that how can I decide upon an optimal CPG Bleed and OUT_PWR value for a very large number of use cases. Basically, I'm using the LMX2581 to generate frequency for such a wide range of frequencies (1GHz-3GHz, with a resolution of at least 1MHz) that it is not feasible to check for what would be optimal for every discrete value, which is why knowing some ballpark value of the parameters from which to choose is the only way out.

    Moreover, it would be acceptable to choose a slightly less than optimal RMS Jitter value by following only what is recommended in the datasheet (CPG Bleed = 0, OUT_PWR = 15), but a 70fs jitter difference is considerable which is why I cannot adopt that approach. For example, when I generate a RFout of 1100MHz (or 2200MHz), changing the CPG Bleed value from 0 to 15 improves RMS Jitter by more than 70fs, but if I change the value of CPG Bleed from 0 to 15 when generating a frequency of 2700MHz it actually degrades the RMS Jitter considerably. The same is the case when I change OUTA_PWR from 15 to 30 for 1100MHz (reduces jitter) and 2700MHz (increases jitter).

    4) I have disabled dithering and set the fractional modulator to 0. Yet again, this observation holds true only for certain frequencies.

    Just to reiterate, the crux of my problem is that there is no consistency in the trends observed across different frequency values. For some frequencies, the recommendations in the data sheet give the best performance, while for others following those gives far from the best results. And this is problematic because of the large number of use cases.

    One solution I can think of is that a simulation software and some scripts are used to look at the effect of each parameter on the noise performance across the entire frequency range that the LMX2581 provides. I'd assumed that something like this would have already been done and put into the datasheet or the information made available elsewhere. But unfortunately that isn't the case. Plus, the clock design tool doesn't provide the flexibility to allow an end user to do these simulations on their own.

    I'm out of ideas on what could work for my application and would be very grateful if you could suggest some way around them.

    Awaiting your reply,

    Thanks and Regards,

    Ajay

  • Hello,

    Still waiting for your reply.
    I'd be very grateful if anyone can help.

    Regards,
    Ajay
  • Dear Ajay,

    I apologize for the delay. We need a little more time to answer the above question. Thank you for your patience.

    Regards,

    Simon.