Common Source: Can zero come before unity crossover?

[exp]

Hi,

I am struggling for long with transistor models of a new process. I get all kinds of weird stuff but specifically: Can the zero of an ordinary diff pair (i.e., Common Source stage) come before the unity crossover?

This is the bode plot I am getting (ac analysis with annotated poles/zeros from pz analysis):

According to hybrid-Pi model, the zero comes from Cgd feedthrough and the zero is given by gm/Cgd

Since Cgd < Cgs (or even Cgg), it must occur after the unity crossover.

Can this really be correct and if yes, why and how? Or can it really be that the transistor model is broken?

 

[Dominik Przyborowski]

If diff pair is loaded by current mirror and your signal path going through positive input and is mirroring on the load I'm not sure if this zero should be always beyond UGF.

 

[exp]

If diff pair is loaded by current mirror and your signal path going through positive input and is mirroring on the load I'm not sure if this zero should be always beyond UGF.

No, no current mirror load. Just ordinary PMOS loads (i.e., current sources)...

 

[Dominik Przyborowski]

It means fully differential configuration? poles-zeros of CMFB?

 

[exp]

Yes fully differential.

Regarding cmbf : Can this really have something to do with? (I will try to run an stb analysis on cmfb...)

However, The cmfb is ideal : I obtain voc via the idealBalun (from vom and vop) , and use an ideal vccs in parallel to the tail current source.

 

[erikl]

Just ordinary PMOS loads (i.e., current sources)...

Ordinary PMOS loads, too, have non-negligible output capacitance which adds to your Cgd. Often current sources are long (and wide), so can add considerable cap.

Check the total capacitance at this node!

 

[exp]

Why to Cgd?

They add caps to the output node (parallel to Cdb) but not back to the input (and hence not Cgd)?

Also,any idea how to measure the actual cap between two nodes (Cgd)? Captab of DC analysis shows 0F

Also the results are not Symmetric in general with nodetonode (same as Cgd! =Cdg). E. G. Node1 to Node2 is different cap value than Node2 to Node1. Makes no sense to me...

 

[erikl]

Why to Cgd? They add caps to the output node (parallel to Cdb) but not back to the input (and hence not Cgd)?

It could enlarge Cgd anyway. Measure it by simulation.

Also,any idea how to measure the actual cap between two nodes (Cgd)? Captab of DC analysis shows 0F

The simplest way to measure a node's total capacitance is to inject a unit current (1A) into this node, run an ac analysis and plot the node's voltage vs. frequency.
Of course biasing the circuit at the proper operation point.

 

[Dominik Przyborowski]

When You calculate transfer function of simple cmos amplifier including Cgd of pmos load and diode connected pfet biasing this load, You get zero caused by both transistors transition frequency, so check if f_t of your pmos fet is close to this zero.

 

[exp]

@erikl: Thanks! But is there also a way to measure capacitance between two nodes? As would be required for this case (the zero)?

@Dominik: Why would I get a zero with the fT of the PMOS? fT of the NMOS is 22GHz, PMOS is 31 GHz ... both seem to be far away from the zero (57 GHz) ...

 

[erikl]

@erikl: Thanks! But is there also a way to measure capacitance between two nodes? As would be required for this case (the zero)?

Current sources (like voltage sources) have 2 nodes. Just connect the current source between the 2 nodes of interest, and plot the voltage between these 2 nodes. With Iac=1A, MV means MΩ .

 

[exp]

Thanks for the hint. This is soooooooo frustrating, really nothing is consistent :-(

At one output node of the diff pair I get:

* 2.85f with the method you described above (ac analysis with 1A differentially injected current)
* 3.81f from captab
* From DC operating point analysis this caps should match Cdb+Csd. They are: Cds = -2.322959f, Cdb = 0.95673222f. Other cap values from dcOpAnalysis: Cbd = 0.80302319f, Csd = 0.11463434f, Cdd = 3.333663f


I really have no idea what I can trust. Why is this all so inconsistent and wrong?

How can you design circuits this way?

 

[erikl]

I really have no idea what I can trust. Why is this all so inconsistent and wrong?

Because of this inconsistency - or you could say: because I was too lazy to delve into SPICE'/SPECTREs art of calculating these confusing captab values - I always relied on the results of "my" a.m. method: simple Ohm's law - and this proved its worth.

Try & check with pole and zero frequencies!

 

[exp]

No, really nothing matches

This is my schematic:



You can see the unit current sources for measuring Cgd and Cout. I always just enable one of them. For the following example, I only measure Cout, i.e., ac_meas_Cout=1, ac_*=0.
Cn are used for neutralization and are yet another thing that gives unexplainable results. However, for this post, Cn=0.

This is the impedance at the output node "vop":



And this is the content of the dcOpAnalysis:

N0.xmmaster.csdext:cap,475.9E-18
N0.xmmaster.m1:beff,21.98E-3
N0.xmmaster.m1:cbb,2.734E-15
N0.xmmaster.m1:cbd,803.0E-18
N0.xmmaster.m1:cbg,1.008E-15
N0.xmmaster.m1:cbs,923.4E-18
N0.xmmaster.m1:cdb,956.7E-18
N0.xmmaster.m1:cdd,3.334E-15
N0.xmmaster.m1:cdg,4.700E-15
N0.xmmaster.m1:cds,-2.323E-15
N0.xmmaster.m1:cgb,577.4E-18
N0.xmmaster.m1:cgd,2.416E-15
N0.xmmaster.m1:cgg,11.89E-15
N0.xmmaster.m1:cgs,8.895E-15
N0.xmmaster.m1:csb,1.200E-15
N0.xmmaster.m1:csd,114.6E-18
N0.xmmaster.m1:csg,6.180E-15
N0.xmmaster.m1:css,7.495E-15
N0.xmmaster.m1:delvg_op,2.706E-3
N0.xmmaster.m1:eg_op,1.124
N0.xmmaster.m1:fug,23.75E9
N0.xmmaster.m1:gds,29.38E-6
N0.xmmaster.m1:gm,1.774E-3
N0.xmmaster.m1:gmb,117.5E-6
N0.xmmaster.m1:gmoverid,17.74
N0.xmmaster.m1:ibe,0.000
N0.xmmaster.m1:idb,0.000
N0.xmmaster.m1:ide,100.0E-6
N0.xmmaster.m1:ids,100.0E-6
N0.xmmaster.m1:ige,13.97E-12
N0.xmmaster.m1:isb,0.000
N0.xmmaster.m1:ise,-100.0E-6
N0.xmmaster.m1:isnoisy,1.000
N0.xmmaster.m1:neff,1.045
N0.xmmaster.m1:ni_op,14.39E15
N0.xmmaster.m1:phit1_op,27.73E-3
N0.xmmaster.m1:phit_op,25.86E-3
N0.xmmaster.m1:pwr,33.00E-6
N0.xmmaster.m1:qgde_op,0.000
N0.xmmaster.m1:qgse_op,0.000
N0.xmmaster.m1:rgate,0.000
N0.xmmaster.m1:rout,34.04E3
N0.xmmaster.m1:self_gain,60.38
N0.xmmaster.m1:vbx_op,-670.6E-3
N0.xmmaster.m1:vds,330.0E-3
N0.xmmaster.m1:vdss,132.2E-3
N0.xmmaster.m1:vdst,330.0E-3
N0.xmmaster.m1:vearly,3.405
N0.xmmaster.m1:vfb_op,-187.6E-3
N0.xmmaster.m1:vfbb_low_op,485.0E-3
N0.xmmaster.m1:vfbb_op,517.5E-3
N0.xmmaster.m1:vgs,530.0E-3
N0.xmmaster.m1:vgst,530.0E-3
N0.xmmaster.m1:vgt,95.40E-3
N0.xmmaster.m1:vsat_marg,197.8E-3
N0.xmmaster.m1:vsb,0.000
N0.xmmaster.m1:vsbt,0.000
N0.xmmaster.m1:vth,434.6E-3
N0.xmmaster.m1:vto,437.3E-3
N0.xmmaster.m1:vts,437.3E-3
N0.xmmaster.rg:i,13.97E-12
N0.xmmaster.rg:pwr,14.15E-21
N0.xmmaster.rg:res,72.49
N0.xmmaster.rg:v,1.013E-9

It can be seen that Rout=1/gds=1/29.38E-6=34.0368e+003. This matches the value from the ac analysis perfectly!

In order to see the cap value, I calculate 1/(2*pi*f*Zout) from above:



It can be seen that Cout = 2.854429fF.

For reference, this is captab:

N0.xmmaster.gi : 0:Fixed,0.000
N0.xmmaster.gi : 0:Total,0.000
N0.xmmaster.gi : 0:Variable,0.000
N0.xmmaster.gi : N0.xmmaster.gi:Fixed,0.000
N0.xmmaster.gi : N0.xmmaster.gi:Total,11.89E-15
N0.xmmaster.gi : N0.xmmaster.gi:Variable,11.89E-15
N0.xmmaster.gi : net5:Fixed,9.472E-15
N0.xmmaster.gi : net5:Total,9.472E-15
N0.xmmaster.gi : net5:Variable,0.000
N0.xmmaster.gi : vip:Fixed,0.000
N0.xmmaster.gi : vip:Total,0.000
N0.xmmaster.gi : vip:Variable,0.000
N0.xmmaster.gi : vom:Fixed,2.416E-15
N0.xmmaster.gi : vom:Total,2.416E-15
N0.xmmaster.gi : vom:Variable,0.000
N1.xmmaster.gi : 0:Fixed,0.000
N1.xmmaster.gi : 0:Total,0.000
N1.xmmaster.gi : 0:Variable,0.000
N1.xmmaster.gi : N1.xmmaster.gi:Fixed,0.000
N1.xmmaster.gi : N1.xmmaster.gi:Total,11.89E-15
N1.xmmaster.gi : N1.xmmaster.gi:Variable,11.89E-15
N1.xmmaster.gi : net5:Fixed,9.472E-15
N1.xmmaster.gi : net5:Total,9.472E-15
N1.xmmaster.gi : net5:Variable,0.000
N1.xmmaster.gi : vim:Fixed,0.000
N1.xmmaster.gi : vim:Total,0.000
N1.xmmaster.gi : vim:Variable,0.000
N1.xmmaster.gi : vop:Fixed,2.416E-15
N1.xmmaster.gi : vop:Total,2.416E-15
N1.xmmaster.gi : vop:Variable,0.000
/net5 : 0:Fixed,0.000
/net5 : 0:Total,0.000
/net5 : 0:Variable,0.000
net5 : N0.xmmaster.gi:Fixed,7.188E-15
net5 : N0.xmmaster.gi:Total,7.188E-15
net5 : N0.xmmaster.gi:Variable,0.000
net5 : N1.xmmaster.gi:Fixed,7.188E-15
net5 : N1.xmmaster.gi:Total,7.188E-15
net5 : N1.xmmaster.gi:Variable,0.000
/net5 : net5:Fixed,951.8E-18
/net5 : net5:Total,17.16E-15
/net5 : net5:Variable,16.21E-15
/net5 : net06:Fixed,0.000
/net5 : net06:Total,0.000
/net5 : net06:Variable,0.000
/net5 : net09:Fixed,0.000
/net5 : net09:Total,0.000
/net5 : net09:Variable,0.000
/net5 : vom:Fixed,917.7E-18
/net5 : vom:Total,1.394E-15
/net5 : vom:Variable,475.9E-18
/net5 : vop:Fixed,917.7E-18
/net5 : vop:Total,1.394E-15
/net5 : vop:Variable,475.9E-18
/net06 : 0:Fixed,0.000
/net06 : 0:Total,0.000
/net06 : 0:Variable,0.000
/net06 : net06:Fixed,0.000
/net06 : net06:Total,0.000
/net06 : net06:Variable,0.000
/net06 : vom:Fixed,0.000
/net06 : vom:Total,0.000
/net06 : vom:Variable,0.000
/net06 : vop:Fixed,0.000
/net06 : vop:Total,0.000
/net06 : vop:Variable,0.000
/net08 : 0:Fixed,0.000
/net08 : 0:Total,0.000
/net08 : 0:Variable,0.000
/net08 : net08:Fixed,0.000
/net08 : net08:Total,0.000
/net08 : net08:Variable,0.000
/net09 : 0:Fixed,0.000
/net09 : 0:Total,0.000
/net09 : 0:Variable,0.000
/net09 : net09:Fixed,0.000
/net09 : net09:Total,0.000
/net09 : net09:Variable,0.000
/vdd! : 0:Fixed,0.000
/vdd! : 0:Total,0.000
/vdd! : 0:Variable,0.000
/vdd! : vdd!:Fixed,0.000
/vdd! : vdd!:Total,0.000
/vdd! : vdd!:Variable,0.000
/vic : 0:Fixed,0.000
/vic : 0:Total,0.000
/vic : 0:Variable,0.000
/vic : vic:Fixed,0.000
/vic : vic:Total,0.000
/vic : vic:Variable,0.000
/vic : vim:Fixed,0.000
/vic : vim:Total,0.000
/vic : vim:Variable,0.000
/vic : vip:Fixed,0.000
/vic : vip:Total,0.000
/vic : vip:Variable,0.000
/vid : 0:Fixed,0.000
/vid : 0:Total,0.000
/vid : 0:Variable,0.000
/vid : vid:Fixed,0.000
/vid : vid:Total,0.000
/vid : vid:Variable,0.000
/vim : 0:Fixed,0.000
/vim : 0:Total,0.000
/vim : 0:Variable,0.000
vim : N1.xmmaster.gi:Fixed,0.000
vim : N1.xmmaster.gi:Total,0.000
vim : N1.xmmaster.gi:Variable,0.000
/vim : vic:Fixed,0.000
/vim : vic:Total,0.000
/vim : vic:Variable,0.000
/vim : vim:Fixed,0.000
/vim : vim:Total,0.000
/vim : vim:Variable,0.000
/vim : vom:Fixed,0.000
/vim : vom:Total,0.000
/vim : vom:Variable,0.000
/vip : 0:Fixed,0.000
/vip : 0:Total,0.000
/vip : 0:Variable,0.000
vip : N0.xmmaster.gi:Fixed,0.000
vip : N0.xmmaster.gi:Total,0.000
vip : N0.xmmaster.gi:Variable,0.000
/vip : vic:Fixed,0.000
/vip : vic:Total,0.000
/vip : vic:Variable,0.000
/vip : vip:Fixed,0.000
/vip : vip:Total,0.000
/vip : vip:Variable,0.000
/vip : vop:Fixed,0.000
/vip : vop:Total,0.000
/vip : vop:Variable,0.000
/voc : 0:Fixed,0.000
/voc : 0:Total,0.000
/voc : 0:Variable,0.000
/voc : voc:Fixed,0.000
/voc : voc:Total,0.000
/voc : voc:Variable,0.000
/voc : vom:Fixed,0.000
/voc : vom:Total,0.000
/voc : vom:Variable,0.000
/voc : vop:Fixed,0.000
/voc : vop:Total,0.000
/voc : vop:Variable,0.000
/vod : 0:Fixed,0.000
/vod : 0:Total,0.000
/vod : 0:Variable,0.000
/vod : vod:Fixed,0.000
/vod : vod:Total,0.000
/vod : vod:Variable,0.000
/vom : 0:Fixed,0.000
/vom : 0:Total,0.000
/vom : 0:Variable,0.000
vom : N0.xmmaster.gi:Fixed,4.700E-15
vom : N0.xmmaster.gi:Total,4.700E-15
vom : N0.xmmaster.gi:Variable,0.000
/vom : net5:Fixed,-1.366E-15
/vom : net5:Total,-890.3E-18
/vom : net5:Variable,475.9E-18
/vom : net06:Fixed,0.000
/vom : net06:Total,0.000
/vom : net06:Variable,0.000
/vom : vim:Fixed,0.000
/vom : vim:Total,0.000
/vom : vim:Variable,0.000
/vom : voc:Fixed,0.000
/vom : voc:Total,0.000
/vom : voc:Variable,0.000
/vom : vom:Fixed,475.9E-18
/vom : vom:Total,3.810E-15
/vom : vom:Variable,3.334E-15
/vop : 0:Fixed,0.000
/vop : 0:Total,0.000
/vop : 0:Variable,0.000
vop : N1.xmmaster.gi:Fixed,4.700E-15
vop : N1.xmmaster.gi:Total,4.700E-15
vop : N1.xmmaster.gi:Variable,0.000
/vop : net5:Fixed,-1.366E-15
/vop : net5:Total,-890.3E-18
/vop : net5:Variable,475.9E-18
/vop : net06:Fixed,0.000
/vop : net06:Total,0.000
/vop : net06:Variable,0.000
/vop : vip:Fixed,0.000
/vop : vip:Total,0.000
/vop : vip:Variable,0.000
/vop : voc:Fixed,0.000
/vop : voc:Total,0.000
/vop : voc:Variable,0.000
/vop : vop:Fixed,475.9E-18
/vop : vop:Total,3.810E-15
/vop : vop:Variable,3.334E-15

As can be seen, neither any combination from captab, nor dcOpAnalysis resembles 2.85f (at least for me).

Now, assuming both dcOpInfo and captab are garbage I calculate the dominant pole:

1/(2piRoutCout) = 29.3766e-6/(2*pi*2.8544e-15)=1.638E9

Here is the result of the pz Analysis:

DC simulation time: CPU = 1 ms, elapsed = 346.899 us.
                      Poles (Hz)

           Real                       Imaginary                 Qfactor

   1   -1.13249e+09                  0.00000e+00              5.00000e-01 
   2   -2.67090e+11                  0.00000e+00              5.00000e-01 

                      Zeros (Hz)
                      at V(vop,vom)/V3

           Real                       Imaginary                 Qfactor

   1    6.00631e+10                  0.00000e+00              -5.00000e-01

Constant factor =  1.91063e+12

DC gain =  6.03826e+01

FAR off to 1.13GHz.
Comparing this to the f3dB of the ac Analysis however, it can be seen that f3dB matches the dominant pole quite well (a clear dominant pole exists here):



Repeating the same with captab value comes at least a bit closer - but still too far off for my taste to trust the values (this is a nearly ideal circuit):

29.3766e-6/(2*pi*3.80956e-15)=1.227E9


So, can you spot anything I am doing wrong? I don't feel I can even start thinking about more complicated circuits when even single transistor circuits are unpredictable and inconsistent

Thank you!


PS: I changed some parameters compared to my original post, hence the pole positions etc. shifted a bit but the qualitative results are the same

 

[erikl]

So, can you spot anything I am doing wrong?

Actually not, sorry!

I don't feel I can even start thinking about more complicated circuits when even single transistor circuits are unpredictable and inconsistent

I don't think it makes much sense to analyze ideal circuits - better try and design real circuits. Ac analyze the open loop circuits, plot the Bode diagrams and check for gain, stability and phase margin, perhaps check with PZ analysis. Then comes closed loop - feedback changes quite a lot - and then the not quite well predictable parasitics from extracted layout. Not even to talk about PVT variations, corner & MC analysis, and - last not least - DFM for better yield. This is how it's done in practice.

I'm sorry if this isn't helpful for your theoretical calculation intentions.

 

[exp]

I don't think it makes much sense to analyze ideal circuits - better try and design real circuits.

This is exactly what I am trying.

Ac analyze the open loop circuits, plot the Bode diagrams and check for gain, stability and phase margin, perhaps check with PZ analysis. Then comes closed loop - feedback changes quite a lot - and then the not quite well predictable parasitics from extracted layout.

This is what I do. But whatever I do things behave the opposite than I would expect:

Example 1: 2 stage amp: I add Miller compensation cap. While I get lower bandwidth, the non-dominant pole is not pushed outwards but I get tons of other poles, zeros which are impossible to relate and result of ac analysis also qualitatively does not look at all how Miller compensation should look like

Example 2: I add the zeroing-resistor Rz=1/gm2 which should push the zero outwards. But again random results in the ac frequency response.

Example 3: I want to use neutralization in a diff pair. Even adding a slight cross coupled capacitance should increase the bandwidth and make it resemble more a decoupled 2 pole system; adding exactly Cgd should completely remove coupling and increase bandwidth. Instead, no matter which value I choose I get smaller bandwidth and tons of other non-intuitive behavior (e.g. complex-valued zeros, weird increase in gain after unity crossover, ...)


How should it be possible to explain these things if it's not even possible to explain explain a single transistor circuit? No, this is for sure not how it's done in practice :-( :-?

 

[exp]

Hi erikl, may I ask once again for your expertise?

1.) I just made the crucial observations that captab and dcOpAnalysis results match precicely:

Cdd = Cbd + Csd + Cgd = 3.333663f
Cdd + Cdsext = 3.333663+0.47589846=3.80956146 -> same as captab value!

2.) The dominant pole of 1.13 GHz requires the following capacitance at the output:

29.3766e-6/(1.13249e+09*2*pi)= 4.1285f

The difference to 3.8f (dcOpInfo & captab) is at least much close to this number than the value I extract using the ac method (2.85443f).

Can't it be that I am indeed making a mistake when using the ac analysis method?

Potential things which could come to my mind:

1.) Do I apply it (see screenshots) correctly for differential circuit?
2.) What is the relation to the Miller approximation for Cgd? It seems that captab + dcOpAnalysis take the capacitance due to the Miller effect into account, i.e., they add Cgd ~ Cgd*(1-1/K) to the output capacitance. How is Cgd taken into account when using the ac analysis method? (just adding Cgd to that value does not work because it would result in 5.27f - too high)

 

[Dominik Przyborowski]

From what You posted, the zero location is ok. Transconductance of your input fet is 1.77mS, cgd is 4.7fF so in first aproximation the zero is located at 60.1GHz. From pz analysis You get 60.06GHz.

 

[erikl]

1.) Do I apply it (see screenshots) correctly for differential circuit?

Checking your screenshot diffpair_single_ac_cout from your post #14:

(3 of 4): I don't understand this plot: Its title says: ac: Impedance at vop , the curve shown is called Cout, showing a value of 4µF @ 1Hz, falling 1 decade per decade. Also, this can't be an Ω resp. V value - what is it? I think you can't get a reasonable Cout value @ 100 PHz from such a curve. Anyway you'd better plot such frequency curves with double-log scaling.

From the previous curve (2 of 4), diffpair_single_ac_zout, title: AC Analysis 'ac': freq = ..., curve name |Zvpp|

- if generated by an ac current source between drain and GND, (how it should be done for the zout measurement at the drain), I could estimate the cout part to a value of ≈4.25 fF (using the 34kΩ-3dB frequency point 1.1GHz, where both parts rout & cout have the same value (34kΩ) and are added quadratically to 24kΩ (34kΩ - 3dB)). For the cout calculation, the impedance of 34kΩ must be used, of course.

Here, too, a double-log curve scaling would be preferable.

 

[exp]

@Dominik: Thanks, indeed, that's great! Haven't looked at the zero since was too much focused on the dominant pole. Do you have any reason (except for the fact that the value matches) to pick Cgd (and not Cdg) for the zero calculation?

@erikl: The first plot shows the capacitance. It is just 1/(2*pi*f*Zout), i.e., 1/(2*pi*xval(pv("/vop" "ac"))*abs(pv("/vop" "ac")))

Maybe you can elaborate how exactly you use ac analysis to deduce the caps?

In a referenced posting you wrote at low frequencies it is the resistance (makes sense) and at high frequencies it shows the cap (makes also sense).

My understanding is that if I make f high enough (e.g. 100PHz) capacitances will dominate and I can calculate the cap value using 1/(2pi*f*Zout). By plotting this I can cross check if I indeed have capacitive behavior: Only if the plot is constant (in my frequency range of interest) there is capacitive behavior involved ... for an ordinary "pole" this must happen at high frequencies up to infinity. I also checked this with ideal transistor models (cccs etc) and it worked.

I could estimate the cout part to a value of ≈4.25 fF (using the 34kΩ-3dB frequency point 1.1GHz, where both parts rout & cout have the same value (34kΩ) and are added quadratically to 24kΩ (34kΩ - 3dB)). For the cout calculation, the impedance of 34kΩ must be used, of course.

If this is true (and my understanding above not) then I have a chicken-egg problem: I don't know 1.1Ghz in the first place, I want to use the resistance value and the estimated capacitance to estimate the pole position in the first place.

So estimating the cap value for one specific, circuit dependent frequency point (other than zero or infinity) makes no real sense to me ...