Large glitch in Phase Noise simulation for PFD + Charge-Pump

One more piece of information, the more I deviate from 25MHz, say 25.01MHz (25MHz + 10kHz) or 25.001MHz (25MHz + 1kHz), the lesser the glitch becomes. The glitch rise only 4.4dB above the noise floor for 25.001MHz ref clock frequency.  

This is probably a numerical issue caused by the fact that the flicker noise (1/f) is infinite at 0Hz and also therefore at exact multiples of the PSS fundamental. If your pnoise points hit exactly the multiples of the PSS fundamental, you're getting these (probably meaningless) values. Normally spectre warns you when you have infinite flicker noise, so I would have expected warnings in the output log spotting that (obviously it can't truly be infinite, but you may see these very big peaks).

At least that's what it sounds like from your description. Slightly moving the fundamental frequency would indeed have the effect of making your pnoise points miss the multiples of the fundamental. 

Does it really make sense to sweep through multiples of the PSS fundamental? What are you trying to actually measure in terms of noise? Measuring the noise over such a huge bandwidth doesn't sound terribly useful to me..

Andrew

Thanks for the reply. I see the following warnings in the output log,

1. Sweep truncated: 100Hz -> 2.23872 GHz.

2. The following results might not be accurate due to undersampling of the actual frequencies above 2.5GHz. 
    Upper side band of 11th harmonic for stimulus frequencies above 2.225GHz and so on.

I am trying calculate the overall noise coming out of PLL. I am not meeting the RJ-rms spec for >20MHz just because of significant portion of this glitch at 100MHz comes out of PLL even after attenuation provided by scaled-version of PLL low-pass transfer function. If I remove this noise source (PFD+CP) and all other noise sources are present (Loop-filter resistor, VCO, Divider and REF clock noise), I meet the spec and, RJ-rms decreases drastically. This is why I was wondering if this glitch is a real thing. 

As you mentioned, what I can do is that run PNOISE till 12.5MHz for a ref clock frequency of 25MHz and keep extending the the noise floor from 12.5MHz till 10GHz when using it for PLL noise analysis. Do you see any concern with this?

Thanks and regards,

Subhadeep

One more thing information I see in the output log related to flicker noise is,

Use full spectrum for normal noise analysis.

MaxSideband for colored noise sources (e.g., 1/f-noise) is set to 20.

It's not obvious to me what you are really trying to measure. I would have expected you'd be interested in the noise at the output of the VCO, and so that presumably would be the jitter at the VCO frequency? You didn't say what your frequency multiplication here is.

Either way, you could use the "jitter" mode which would sample the noise (at the PSS fundamental) which would cause the noise at all sidebands to be folded into the band from DC up to half the PSS fundamental - and then you would only need to sweep the pnoise (and compute the jitter) up to half the PSS fundamental. In current versions there's even a checkbox to limit the pnoise analysis to half the PSS fundamental when using jitter mode.

Just simulating up to 12.5MHz and extrapolating (if you're not using this jitter mode) is not going to give the right answer. With jitter mode there's an ideal sampler at the output of the circuit which causes all sidebands to be folded into the band up to half the PSS fundamental. That sounds as if it's probably what you want?

Regards,

Andrew.

Yes I am interested in the noise at at the output of the VCO. The ref clock frequency is 25MHz and the VCO frequency is 6GHz. So, frequency multiplication factor is 240.

I am doing the system-level simulation with all ideal elements used from analogLib to mimic the PLL parts. Also feeding in the noise at the different noise sources i.e., the noise contribution of PFD+CP, Loop-filter resistor, VCO, Divider and REF clock noise. Yes, ideally what I would expect beyond the PLL bandwidth is that only VCO noise should come out. But I see this glitch also coming out. The PLL bandwidth is set at 1.5MHz. I see this glitch near 100MHz. The PLL is to be used in a wireline application with 6Gbps speed. So, when I am integrating the noise at the VCO output from 20MHz till 3GHz with all the noise sources present, I am seeing higher jitter due to the glitch. 

In this setup, when I am removing the PFD+CPP alone or using its noise when simulated with 25.01MHz ref clock frequency, I see a drastic improvement at the jitter (again the integration bandwidth being 20MHz to 3GHz).

I did not know about the "jitter" mode you mentioned. I was using "time-average/USB" for PNOISE analysis. 

Dear subadeepdatta,

Sorry for the slow reply as I saw your initial post but was busy with work...but here goes with a few comments that, if you have time, you might consider

subhadeepdatta said:

I am doing the system-level simulation with all ideal elements used from analogLib to mimic the PLL parts. Also feeding in the noise at the different noise sources i.e., the noise contribution of PFD+CP, Loop-filter resistor, VCO, Divider and REF clock noise.

I have a number of concerns with your simulation methodology.

1. I noticed you have the "Detect steady-state" feature enabled. In your netlist. However, you have what is termed a stiff set of differential equations as the time constants vary by orders of magnitude. You have a VCO that is running, presumably at 240*25 MHz = 6 GHz and a loop bandwidth that may be on the order of 1 MHz+ (guess?). Hence, the time constants differ by roughly 5*6 GHz/1 MHz ~30 GHz/1 MHz = 300,000. I do not know what stabilization time is used prior to PSS convergence, but if it is not sufficient to guarantee your loop has truly reached a solution that accurately predicts the PSS solution, your pnoise results will be corrupted. Have you examined the steady-state solution? You may need to increase reltol to more accurately estimate both VCO and the PLL phase performance. Even conventional transient simulations of such a PLL requires much "care" in selecting transient simulation accuracy settings to predict the output phase behavior accurately.

2. A second concern is the manner in which you are attempting to predict the noise of the PFD/CP. Since you have set the beat frequency to 25 MHz - a single period of the reference clock, your steady-state solution will only contain a single cycle of the reference clock. However, this does not provide a good estimate of what your actual steady-state phase noise of the PFD/CP. Why do I make this comment? The steady-state behavior of the PFD/CP output, if you were to measure its current versus time, will consist or a random set of very narrow up and down currents that will occur at roughly 25 MHz intervals. Hence, it will consist of noise contributions from nmos and pmos current sources that will average to a value that produces a 6 GHz/240 frequency whose phase is aligned to an edge of the 25 MHz reference clock. However, in your case, with only a single period of the 25 MHz reference clock in the steady-state estimate, you are not capturing the proper noise of the PFD/CP output. In essence, you will not see the CP outputs from both pmos and nmos current sources in your charge pump and, more importantly, will not see the true steady-state performance of the signal - which means the PLL PSS solution can not possibly represent  steady-state behavior.

3. In my experience, it is far more efficient to simulate the phase noise of the PFD/CP as a separate entity, as well as other loop components and then combine the results using the well known relationships governing their phase noise contributions to the PLL output noise. This approach has been quite successful in predicting the phase-locked loop output noise in many generations of technologies. It also eliminates many of the concerns I mention in [1] and [2]. Is this something you have considered as an option subadeepdatta?

In summary, my personal thought is that the "steady-state solution" the simulator has reached and is using to determine phase noise is not a reasonable estimate of the actual steady-state and hence the phase noise results will be reliable and, rather, counterintuitive - as you have experienced.

Shawn

Thanks Shawn for the detailed reply.

May I was not clear enough, my description was a little bit confusing but I am doing precisely what you mentioned in [3]. Characterizing the noise from PFD/CP as a separate entity. Also doing the same for all loop elements such as VCO, feedback divider, loop-filter, input ref clock noise separately from each other. All those noise sources can then be fed in to a MATLAB/Octave script to get the overall PLL output noise. The same thing can also be done using Cadence macro-model simulation where we can model the transfer functions all PLL-loop elements using analogLib elements (for example, PFD+CP being modeled as a voltage-controlled current source with a gain of ICP/6.28, feedback divider being modeled as a voltage-controlled voltage source with a gain of 1/N, VCO modeled as a voltage-controlled current source with gain of 6.28*KVCO pumping current into a 1F ideal capacitor to mimic the 6.28*KVCO/s equivalent in s-domain). The noise files are then fed in using voltage or current sources at the respective nodes of the loop.

I am not performing transient or PSS in this test bench. I am doing ac- and noise-analysis. The 1st one provides information on the loop small-signal stability parameters (PM, loop bandwidth) and the later gives us estimate on overall noise performance at the PLL output.

You mentioned very useful points in [1] but I am only doing PSS/PNOISE while characterizing noise from PFD/CP as a separate entity and similarly from VCO, feedback divider, loop-filter. I think your inputs in [1] will be very useful while doing PLL top-level transient simulations to check its large-signal stability, locking behavior. etc.

I think what you have mentioned in [2] is based on the impression that I am doing PLL PSS+PNOISE simulation with detect steady-state enabled and PSS beat frequency of 25MHz. But that is not what I am doing. I hope that is clear from the above section (let me know if it is still not clear?). After the PLL reaches a steady-state, PFD will keep on generating reset pulses in both UP and DN during which CP will keep on dumping noise currents from NMOS and PMOS current sources which are not uncorrelated. Therefore, performing PSS+PNOISE for PFD+CP as a separate entity ensures that it returns an averaged out power-spectral density of the PFD+CP output noise current which is what then used for the PLL output noise estimation. I guess this pretty much takes into account the time-varying aspect of the power-spectral density of the PFD+CP noise current (a cyclo-stationary process) which then can be used to estimate the PLL output noise with a decent enough accuracy level. Do you have a different view on this? Please let me know.