• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Mixed-Signal Design
  3. PLL Verification RAK - Total Phase Noise

Stats

  • Locked Locked
  • Replies 14
  • Subscribers 65
  • Views 8151
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PLL Verification RAK - Total Phase Noise

JoJakNap
JoJakNap over 1 year ago

Hello,

I've been going through the PLL Verification RAK. I have some experience with PLLs but I guess not enough to understand how the calculated total phase noise is done in this RAK.

  1. In the RAK, the phase noise is measured for each component and injected into an appropriate node of the loop using verilog-A - which is an awesome idea.
  2. The same test bench is used to measure response time of the PLL - which is great re-use and I love it.
  3. from (1) and (2) I'm concluding that the noise sources are Volts/Sqrt(Hz) and the transfer functions are not magnitudes.

Question:

  1. Strangely the VCO Phase noise looks like it is 1/f and white not 1/f^3 and 1/f^2 and white. Why?
  2. In the section where the total phase noise is summed, all noise sources appear to be summed together directly - as opposed to summing their squares and taking square root at each frequency.

Are these two correct? And if so can someone explain why?

Thank you

 

  • Cancel
Parents
  • ShawnLogan
    ShawnLogan over 1 year ago

    Dear JoJakNap,

    JoJakNap said:
    Are these two correct? And if so can someone explain why?

    I apologize for my late response! I took some time to study the relevant sections of the PLL Verification RAK you referred to and assembled a response to each of your questions I hope I understood them correctly!

    To answer each question, I had to extract the data from the plots shown in the RAK in order to perform the analysis. A summary of my responses and the analysis are attached. The attached file has a reduced resolution as Forum guidelines prevent me from uploading files over about 1 MB.  If you have any trouble reading it, the full resolution file may be found at:

    Once, again, I cannot include a non-Cadence link in my response, but to allow you to access the note if you are interested, you may copy and append the following into your browser following the usual internet prefix.

    1drv.ms/

    b/s!AnM-GsAEZPoSsBllFBcFZdlaortS?e=cxwds0

    Let me know if you have any questions or comments JoJokNap, and I hope this is not too late to be useful to you!

    Shawn

    PLL_verification_WS_rak_questions_121723v1p0.pdf

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • ShawnLogan
    ShawnLogan over 1 year ago

    Dear JoJakNap,

    JoJakNap said:
    Are these two correct? And if so can someone explain why?

    I apologize for my late response! I took some time to study the relevant sections of the PLL Verification RAK you referred to and assembled a response to each of your questions I hope I understood them correctly!

    To answer each question, I had to extract the data from the plots shown in the RAK in order to perform the analysis. A summary of my responses and the analysis are attached. The attached file has a reduced resolution as Forum guidelines prevent me from uploading files over about 1 MB.  If you have any trouble reading it, the full resolution file may be found at:

    Once, again, I cannot include a non-Cadence link in my response, but to allow you to access the note if you are interested, you may copy and append the following into your browser following the usual internet prefix.

    1drv.ms/

    b/s!AnM-GsAEZPoSsBllFBcFZdlaortS?e=cxwds0

    Let me know if you have any questions or comments JoJokNap, and I hope this is not too late to be useful to you!

    Shawn

    PLL_verification_WS_rak_questions_121723v1p0.pdf

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
  • Binhngo1210
    Binhngo1210 over 1 year ago in reply to ShawnLogan

    By the way your answer and curious by JoJakNap question, so i took a look at page 59 (Action 78).I think there is a wrong comment here about VCO phase noise. the correct one shoule be " the injected VCO phase noise is high pass filtered ....." not low pass




    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • JoJakNap
    JoJakNap over 1 year ago in reply to ShawnLogan

    Dear Shawn,
    Thank you for taking the time and making a very detailed response.

    Regarding questions 1:
    I am running the simulations in the RAK and the simulations show that the power spectral density is 1/f^3 -> 1/f^2 and if I add a buffer I also see white noise at high freq.

    But there is a test bench in the RAK that is used to simulate the PLL closed loop response noise. The test bench uses verilog a to inject the VCO noise as an additive source and its verilog-A is:

    module VNoiseFlickerWhite(out);
    output out;
    electrical out;

    parameter real flickerPSDat1Hz = 1e-5; //flicker nosie PSD at 1Hz, V^2/Hz
    parameter real flicker_freq_exp = 1; // frequency exponent for 1/(freq^exp)
    parameter real whitePSD = 1e-18; //white noise PSD, V^2/Hz

    analog begin

    V(out) <+ flicker_noise(flickerPSDat1Hz, flicker_freq_exp);
    V(out) <+ white_noise(whitePSD);

    end
    endmodule

    This code generates 1.f + white noise. It does not generate the 1/f3 portion of the phase noise. It also states that the noise is PSD, V^2/Hz.

    Regarding Questions 2

    The same test bench is used for time domain response. This means that the filters and all the gain stages must interact with V and not V^2, and the time domain analysis is in V. But when re-using the test bench for noise simulation, you must either take each noise source and make the units V/sqrt(hz) so that it can be operated on by the filters as is, or one would need to change the filters to |H(s)|^2 and have the noise be of unit V^2/Hz.

    Lastly

    When the different noise sources are summed together, if we use V/sqrt(Hz) like the test bench has done, we can't just add the different sources of noise together. We need to add their power's together. But as far as I can understand, the source of noise and the filter and gain stages are not squared and therefore in units of V/sqrt(hz) and they need to individually be squared, and then summed. Which is not what the test bench in the RAK is doing.

    Thanks for your time and the pdf you generated. Please if you have time see if I am missing something.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to Binhngo1210

    Dear Binhngo1210,

    Binhngo1210 said:
    I think there is a wrong comment here about VCO phase noise. the correct one shoule be " the injected VCO phase noise is high pass filtered ....." not low pass

    Yes. The statement you refer to on page 59 is rather misleading. The author "somewhat" corrects his or her statement beneath the second figure of Action 78 on page 60 describing the action of the closed loop transfer function for the DSM noise (see Figure 1).

    However, in my opinion, neither statement really enhances one's understanding of the impact of the noise of each of the phase-locked loop components on the total output noise of the phase-locked loop. If I had to re-write the statements, I might include something like the following:

    The noise of a phase-locked loop's reference oscillator and its individual components each contribute to its total output noise. The manner in which the reference oscillator noise and each component's noise contribute differ as a result of where the noise of each is injected (outside or within the phase-locked loop).

    Further, the contribution of each noise source is dependent on the loop gain of the phase-locked loop (of which the individual components play a major role). In other words, the contribution of a given phase-locked loop component to the output noise is a function of both the noise of that component and the overall loop gain.

    The reference oscillator noise contribution to the total output noise is conceptually and mathematically easiest to understand and compute. Its noise serves as an input to the phase-locked loop and hence its filtered by the transfer function of the phase-locked loop itself. Since the transfer function of a phase-locked loop is low pass in nature with potential transfer function peaking, the noise contribution of the reference oscillator to the output noise is the reference oscillator noise filtered by the phase-locked loop transfer function.

    Since the phase detector and any potential loop filter are contained in the forward loop path of the phase-locked loop, each of their noise sources are filtered by the closed-loop transfer function of the phase-locked loop.

    The VCO noise consists of two components: the innate VCO noise (as a standalone component); and the added signal and noise introduced into its control voltage input by the output of the phase-detector, loop filter and divider. For frequencies where the loop gain is large, the control voltage input will cancel the VCO innate noise and match the noise of the reference oscillator. However, as the loop gain becomes smaller at higher frequencies, it will not be able to totally match the reference oscillator noise and the phase-locked loop output noise will start to reflect the innate noise of the VCO. Intuitively, this suggests the noise contribution of the VCO to the total output noise consists of the highly attenuated VCO noise at low frequencies that gradually increases to the innate VCO noise as the loop gain approaches unity (i.e., the closed loop transfer function bandwidth). Therefore, the VCO noise transfer function is high pass in nature whose characteristic is determined by the inverse of the low pass phase-locked loop transfer function.

    The DSM noise is effectively injected at the same point as the VCO output node within the phase-locked loop. As such, its noise contribution to the total output noise is also filtered by the inverse of the low pass phase-locked loop transfer function - which is high pass in nature but NOT as the text indicates "high pass filtered by the closed-loop PLL transfer function to the output phase noise".

    I hope this is consistent with your thinking Binhngo1210. Let me know if it is not!

    Shawn

    Figure 1

    Page 60 of reference [1]

    [[1] "PLL Verification Rapid Adoption Kit (RAK)", Product Version IC 6.1.8, MMSIM 21.1, XCELIUM 21.09 May, 2022

    • Cancel
    • Vote Up +1 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to JoJakNap

    Dear JoJakNap,

    JoJakNap said:
    Thank you for taking the time and making a very detailed response.

    Of course, I just hope it was of some use to you!

    Please allow me to comment on each of your questions if I may...

    JoJakNap said:

    Regarding questions 1:
    I am running the simulations in the RAK and the simulations show that the power spectral density is 1/f^3 -> 1/f^2 and if I add a buffer I also see white noise at high freq.

    But there is a test bench in the RAK that is used to simulate the PLL closed loop response noise. The test bench uses verilog a to inject the VCO noise as an additive source and its verilog-A is:

    module VNoiseFlickerWhite(out);
    output out;
    electrical out;

    parameter real flickerPSDat1Hz = 1e-5; //flicker nosie PSD at 1Hz, V^2/Hz
    parameter real flicker_freq_exp = 1; // frequency exponent for 1/(freq^exp)
    parameter real whitePSD = 1e-18; //white noise PSD, V^2/Hz

    analog begin

    V(out) <+ flicker_noise(flickerPSDat1Hz, flicker_freq_exp);
    V(out) <+ white_noise(whitePSD);

    end
    endmodule

    This code generates 1.f + white noise. It does not generate the 1/f3 portion of the phase noise. It also states that the noise is PSD, V^2/Hz.

    You are absolutely correct in that the verilog-A code you found for the VCO noise model generates only white and 1/f flicker noise. For some reason, in the Cadence RAK we are discussing, the authors elected to ONLY include the white and 1/f components of noise for the VCO. Please see the text I quote from the document on page 56.

    From page 56:

    "As indicated in the note next to the VCO noise source (top-right circle), this test bench models both flicker and white noise contributions. The VCO noise characterization has been covered earlier. Here, you model the noise source by curve-fitting to the characterized noise. "

    Hence, the authors did not elect to include the higher order noise terms found in the VCO characterization and hence this is why they are not in the model.

    It is also a correct statement that PSD arguments to the flicker_noise() and white_noise() functions are expressed in V^2/Hz. Please note, however, that V(out) is not the PSD function, but the voltage resulting from the flicker_noise() or white_noise() verilog-A functions. These functions produce a voltage or current noise and do not have the units of V^2/Hz or I^2/Hz. Please refer to their definitions in the Verilog-A Language Reference for more information.

    JoJakNap said:

    Regarding Questions 2

    The same test bench is used for time domain response.

    When test bench "pll_phase_domain_sim" is used in the transient simulation, all noise sources are turned off and hence are irrelevant. Hence, it is only simulating the large signal response of the loop using its small-signal parameters. Further, it is simulating the phase response - not the voltage response.

    JoJakNap said:

    Lastly

    When the different noise sources are summed together, if we use V/sqrt(Hz) like the test bench has done, we can't just add the different sources of noise together. We need to add their power's together. But as far as I can understand, the source of noise and the filter and gain stages are not squared and therefore in units of V/sqrt(hz)

    I mention this specifically on page 5 of the note I attached, and repeated below as Figure 3, the assumption I made is that the y-axis reflects 20*log10( signal in V/root Hz). This is the same as 10*log10(signal in V^2/Hz) - which is power and reflects the conventional units for a power spectral density. Therefore, I computed the power sum by summing the linear power values for each noise component and for the total noise as Pi = 0^[(y-axis value)/10].

    Shawn

    Figure 3

    from page 5 of prior attached file

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Binhngo1210
    Binhngo1210 over 1 year ago in reply to ShawnLogan

    thanks for detailed words, hope it helps for other members too 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to Binhngo1210

    Dear Binhngo1210,

    Binhngo1210 said:
    for detailed words,

    I am just amazed you managed to read them all!

    I also hope it is instructive for others with an interest. Thank you Binhngo1210!

    Shawn

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • JoJakNap
    JoJakNap over 1 year ago in reply to ShawnLogan

    Dear Mr Shawn,
    Thank you for your insight and confirming the incompleteness of the verilog-a model. I have progressed in the RAK and started looking at the PFD and charge pump section and I see that the simulation that the RAK recommends is reasonable and so are the results of the simulation which are in units of Amps/sqrt(Hz).

    However, the verilog-a that is used for the PFD+CP noise injection is same file that is used for VCO :

    module VNoiseFlickerWhite(out);
    output out;
    electrical out;

    parameter real flickerPSDat1Hz = 1e-5; //flicker nosie PSD at 1Hz, V^2/Hz
    parameter real flicker_freq_exp = 1; // frequency exponent for 1/(freq^exp)
    parameter real whitePSD = 1e-18; //white noise PSD, V^2/Hz

    analog begin

    V(out) <+ flicker_noise(flickerPSDat1Hz, flicker_freq_exp);
    V(out) <+ white_noise(whitePSD);

    end
    endmodule

    Note that the noise is in V(out) and not I(out).

    However, from Mr. Ken Kundert's document on this matter I see the following code: 

    I believe that this is an error in the RAK similar to the VCO's 1/f3 and 1/f2 noise being excluded, but I don't have the command on this subject matter. Please if you can share your insights when you can.

    Happy Holidays to you sir.

    -JJ

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to JoJakNap

    Dear JoJakNap,

    Thank you for reading my comments! It is clear you are making good progress through the RAK and studying it carefully - very good!

    I hope you had a nice Christmas too! I took some time to review your added questions and have compiled a summary of my efforts. I included it as "Part 2" of the prior set of notes and uploaded it to the same location as v.10 of the note at:

    You may, as before, copy and append the following text strings to form the address in your favorite browser:

    1drv.ms/

    b/s!AnM-GsAEZPoSsBllFBcFZdlaortS?e=cxwds0

    The added section 2 entitled "Part 2: Additional Question 3 from Cadence Forum Post" starts on page 16. I tried to answer each of your 3 questions which I labeled (a), (b), and (c).

    (a)

    JoJakNap said:
    However, the verilog-a that is used for the PFD+CP noise injection is same file that is used for VCO :

    (b)

    JoJakNap said:
    I believe that this is an error in the RAK similar to the VCO's 1/f3 and 1/f2 noise being excluded, but I don't have the command on this subject matter. Please if you can share your insights when you can.

    and

    (c)

    JoJakNap said:
    Note that the noise is in V(out) and not I(out).

    In summary, I agree with you that the verilog-A model used for the PDF_CP noise appears to have the same form as that for the VCO noise model and does not accurately represent the large signal pss/pnoise analysis result from the Rapid-Adoption Kit.  I include some further comments on this in the note. However, I also attempted to use the verilog-A PFD_CP model and its VCO parameters to compare the closed loop noise contribution of the verilog-A PFD_CP to the PLL and found it did not correlate well with the result found in the PLL phase domain simulation result for offset frequencies over about 10 kHz. I derived the PFD-CP noise from the PLL result for the PFD_CP noise contribution and the PLL transfer function provided on page 14 of the RAK and found its PSD at 1 Hz (1/f noise at 1 Hz) and its thermal noise term.

    This lead me to the question I included in the note for you:

    Is there a chance the verilog-A model parameter whitePSD is set by the PFD_CP instance of the verilog-
    A block and not using its default value of 1e-18 in the verilog-A code?

    In other words, if you do a query ("Shift-Q') of the PFD_CP instance of VnoiseFlickerWhite and inspect its veriloga parameters, is there a value assigned to parameter "whitePSD" that is different than the default value of 1e-18? I suspect there is.

    Let me know if I can answer any questions or clarify anything. I am unable to upload the actual document as it is too large for Forum guidelines...sorry!

    Shawn

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 1 year ago in reply to ShawnLogan

    There's an awful lot of speculation in this thread which would have been much more simply solved by speaking to somebody who actually had access to the RAK rather than just a copy of the document. This is what customer support is for. I would have responded sooner, but had to wade through Shawn's very lengthy replies and documents which took rather longer than answering the original questions would have.

    Anyway, the key here (to JJ's last questions) are that whilst the models are the same, the parameters are not. I adjusted the CDF settings so that both instances can show their parameters in the property assistant at the same time:

    As you can see, they have different parameters for both the flicker and the white noise.

    The fact that the output is in volts doesn't really matter here - the whole point is that the entire model uses voltages to represent phase - which makes life simpler by modelling the various gains as Laplace voltage-controlled-voltage-sources (svcvs). If they were currents outputs, then the ON_LPF, ON_PFD, ON_VCO etc would have needed to be sccvs to correct for that.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • ShawnLogan
    ShawnLogan over 1 year ago in reply to Andrew Beckett

    Dear Andrew,

    Andrew Beckett said:
    Anyway, the key here (to JJ's last questions) are that whilst the models are the same, the parameters are not. I adjusted the CDF settings so that both instances can show their parameters in the property assistant at the same time:

    Thank you for both taking your valuable to review my comments and provide the verilog-A pfd/cp model parameters! I suspected the default model parameter values were replace with instance based parameters and had asked Mr. JoJak Nap to confirm that.

    However, the values you provided are not consistent with the simulated PFD_CP noise contribution to the PLL shown in the figure on page 60 of the note. Something is stll amiss. I computed the noise contribution of the PFD_CP to the PLL using its transfer function (from the RAK, page 14) and its charge pump gain and divider using your parameters and updated the note to v1.2 with the result. I also determined the set of model parameters whose noise contribution does correlate well with PFD-CP noise contribution on page 60. Slide 25 of the updated note contains the result and is included below if you are interested.

    Shawn

    Slide 25 from v1.2 of note at

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information