+ Post New Thread
Results 1 to 13 of 13

13th January 2019, 11:04 #1
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
dc sweep convergence issue for cmos inverter
I am having some convergence issue with DC sweep for a CMOS inverter.
To duplicate the exact issue, see the following log as well as the attached netlist files, together with modelcard.nmos and modelcard.pmos
I have tried various suggestions online (such as bypassing .op analysis , using smaller dc sweep step, use .ic initial condition, add parasitic resistance to circuit nodes), but those do not help in my case.
Code:[phung@archlinux frequency_trap]$ make test_CMOS_Inverter.net gnetlist L ../.. g spicenoqsi test_CMOS_Inverter.sch o test_CMOS_Inverter.net reading specific gafrcLoading schematic [/home/phung/Documents/Grive/Personal/Analog/Active_Inductor/frequency_trap/test_CMOS_Inverter.sch] [phung@archlinux frequency_trap]$ ngspice test_CMOS_Inverter.net ngspice30 : Circuit level simulation program The U. C. Berkeley CAD Group Copyright 19851994, Regents of the University of California. Please get your ngspice manual from http://ngspice.sourceforge.net/docs.html Please file your bugreports at http://ngspice.sourceforge.net/bugrep.html Creation Date: Thu Jan 3 04:39:51 UTC 2019 Circuit: * gnetlist l ../.. g spicenoqsi o test_cmos_inverter.net test_cmos_inverter.sch Doing analysis at TEMP = 25.000000 and TNOM = 27.000000 No. of Data Rows : 1 @m.x1.m1[gds] = 0.000000e+00 @m.x1.m1[gm] = 2.080796e03 @m.x1.m2[gds] = 5.094415e03 @m.x1.m2[gm] = 1.145951e03 cout = 2.997462e+00 v_ip_out#branch = 2.99746e11 vd#branch = 1.71460e03 vdd = 3.300000e+00 vin = 1.650000e+00 vin#branch = 0.000000e+00 vout = 2.997462e+00 vs#branch = 1.714603e03 vss = 0.000000e+00 Doing analysis at TEMP = 25.000000 and TNOM = 27.000000 ^Ceference value : 0.00000e+00 Interrupted once . . . doAnalyses: Too many iterations without convergence dc simulation interrupted Doing analysis at TEMP = 25.000000 and TNOM = 27.000000 No. of Data Rows : 100 ngspice 1224 > listing * gnetlist l ../.. g spicenoqsi o test_cmos_inverter.net test_cmos_inverter.sch 2 : .param supply=3.3v 3 : .global gnd 6 : x1 vin vout inv1 7 : vs vss 0 0v 8 : vin vin 0 dc {supply/2} ac 1 9 : vd vdd 0 {supply} 10 : v_ip_out cout vout dc 0v 11 : r1 0 cout 100g 12 : cout 0 cout 1n 14 : .model n1 nmos 15 : .model p1 pmos 16 : .global vdd vss 21 : .subckt inv1 2 1 23 : m2 1 2 vdd vdd p1 l=0.4u w=3u m=25 24 : m1 1 2 vss vss n1 l=1.2u w=3u m=25 26 : .ends 28 : .control 29 : save all @m.x1.m1[gm] 30 : save all @m.x1.m2[gm] 31 : save all @m.x1.m1[gds] 32 : save all @m.x1.m2[gds] 33 : op 34 : print all 35 : dc vin 0 vd 0.1 36 : ac lin 100 1 10g 37 : let gm=(i(v_ip_out))/vin 38 : plot gm 39 : print gm > transconductance_of_cmos_inverter.log 40 : .endc 13 : .options temp=25 41 : .end ngspice 1225 > listing expand * gnetlist l ../.. g spicenoqsi o test_cmos_inverter.net test_cmos_inverter.sch 23 : m.x1.m2 vout vin vdd vdd p1 l=0.4u w=3u m=25 24 : m.x1.m1 vout vin vss vss n1 l=1.2u w=3u m=25 7 : vs vss 0 0v 8 : vin vin 0 dc 1.64999999999999991e+00 ac 1 9 : vd vdd 0 3.29999999999999982e+00 10 : v_ip_out cout vout dc 0v 11 : r1 0 cout 100g 12 : cout 0 cout 1n 14 : .model n1 nmos 15 : .model p1 pmos 13 : .options temp=25 26 : .end ngspice 1226 >
Code:* gnetlist L ../.. g spicenoqsi o test_CMOS_Inverter.net test_CMOS_Inverter.sch * SPICE file generated by spicenoqsi version 20170819 * Send requests or bug reports to jpd@noqsi.com X1 Vin vout INV1 Vs Vss GND 0V Vin Vin GND AC 1 Vd Vdd GND 'SUPPLY' V_IP_out Cout vout DC 0V R2 GND Vin 100G R1 GND Cout 100G Cout GND Cout 1n .PARAM SUPPLY=3.3v .options TEMP=25 .IC v(Vin)=1.65 v(Vout)=1.65 .MODEL n1 NMOS .MODEL p1 PMOS .GLOBAL Vdd Vss .INCLUDE CMOS_Inverter.net .control save all @m.x1.m1[gm] save all @m.x1.m2[gm] save all @m.x1.m1[gds] save all @m.x1.m2[gds] *op print all dc Vin 0 Vd 0.01 ac lin 100 1 10G let Gm=(i(v_ip_out))/Vin plot Gm print Gm > Transconductance_of_CMOS_inverter.log .endc
Code:* gnetlist L ../.. g spicenoqsi o CMOS_Inverter.net CMOS_Inverter.sch * SPICE file generated by spicenoqsi version 20170819 * Send requests or bug reports to jpd@noqsi.com .subckt INV1 2 1 * M2 1 2 Vdd Vdd P1 l=0.4u w=3u m=25 M1 1 2 Vss Vss N1 l=1.2u w=3u m=25 * .ENDS

13th January 2019, 20:39 #2
 Join Date
 Mar 2008
 Location
 USA
 Posts
 6,207
 Helped
 1797 / 1797
 Points
 38,358
 Level
 47
Re: dc sweep convergence issue for cmos inverter
So you are running a simulation based on MOSFET models
with only default / unknown parameters, and you are
upset about a result (or a result taking too long)?
Cout = 3 Farads in the run log, and this raises no
questions? Should not affect DC / OP, but from the
text seems like maybe your FET models are way whacked
for size (because you left them "whatever"?).

14th January 2019, 02:43 #3
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
Re: dc sweep convergence issue for cmos inverter
based on MOSFET models with only default / unknown parameters
Cout = 3 Farads in the run log

Advertisment

14th January 2019, 04:36 #4
 Join Date
 Mar 2008
 Location
 USA
 Posts
 6,207
 Helped
 1797 / 1797
 Points
 38,358
 Level
 47
Re: dc sweep convergence issue for cmos inverter
Yes, and nowhere in what's shown are any model params declared.
Only geometric devicecard arguments.
Where did you get this ? I can only see Cout = 1n
Doing analysis at TEMP = 25.000000 and TNOM = 27.000000
No. of Data Rows : 1
@m.x1.m1[gds] = 0.000000e+00
@m.x1.m1[gm] = 2.080796e03
@m.x1.m2[gds] = 5.094415e03
@m.x1.m2[gm] = 1.145951e03
cout = 2.997462e+00
....

Advertisment

14th January 2019, 05:20 #5
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
Re: dc sweep convergence issue for cmos inverter
Doing analysis at TEMP = 25.000000 and TNOM = 27.000000
No. of Data Rows : 1
@m.x1.m1[gds] = 0.000000e+00
@m.x1.m1[gm] = 2.080796e03
@m.x1.m2[gds] = 5.094415e03
@m.x1.m2[gm] = 1.145951e03
cout = 2.997462e+00
Yes, and nowhere in what's shown are any model params declared.
Only geometric devicecard arguments.

Advertisment

14th January 2019, 13:26 #6
 Join Date
 Nov 2013
 Posts
 611
 Helped
 148 / 148
 Points
 4,048
 Level
 14
Re: dc sweep convergence issue for cmos inverter
You get the node voltage of the output capacitor and you have convergence issue? These are opposite things. How is it possible? I don't understand the issue here.
I have no idea how ngspice operates, but if you really have convergence issues you can set probably relative/absolute tolerances of the solver. You didn't mention these, I would try to set those."Try SCE to AUX." /John Aaron/

14th January 2019, 14:44 #7
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
Re: dc sweep convergence issue for cmos inverter
You get the node voltage of the output capacitor and you have convergence issue?
you can set probably relative/absolute tolerances of the solver

14th January 2019, 14:59 #8
 Join Date
 Nov 2013
 Posts
 611
 Helped
 148 / 148
 Points
 4,048
 Level
 14
Re: dc sweep convergence issue for cmos inverter
Ok, I see, but gmin is not equal with reltol and abstol. Can you set these for DC sweep, you tried these?
As I see in this manual you can set many options: iteration number, tolerances, methods. If you tried to set these we can move forward.Last edited by frankrose; 14th January 2019 at 15:04.
"Try SCE to AUX." /John Aaron/
1 members found this post helpful.

14th January 2019, 19:47 #9
 Join Date
 Mar 2008
 Location
 USA
 Posts
 6,207
 Helped
 1797 / 1797
 Points
 38,358
 Level
 47
Re: dc sweep convergence issue for cmos inverter
.MODEL n1 NMOS
.MODEL p1 PMOS
Are your model cards. So your FETs' compact model
attributes are all whatever is default. Element card only
says "how big". If there is any embedded numerical
singularity / nonmonotonicity resulting from the mash
of "somebody thought this was a good idea" default
values, "boom" goes the solver.
You might try to find FET models that match the
technology, or at least process node, just to see if a
knowngood model eliminates the convergence issues.
It's certainly possible to apply .model arguments which
directly cause numerical problems.

14th January 2019, 21:41 #10
 Join Date
 Nov 2013
 Posts
 611
 Helped
 148 / 148
 Points
 4,048
 Level
 14
Re: dc sweep convergence issue for cmos inverter
To add some thoughts for dick_freebird's comment it is suspicious for me the supply is not mentioned in the comments of these modelcards, however Vth0 is quite low, 0.25V for both devices.
I am not sure these transistors can tolerate 3.3V supply voltage without breakdown, and if you try to operate a transistor in breakdown region maybe it can increase the chance of convergence issues.
Next to these models which is very attractive that they are free and those guys released who worked on the BSIM4 transistor models on the Berkeley."Try SCE to AUX." /John Aaron/

15th January 2019, 02:25 #11
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
Re: dc sweep convergence issue for cmos inverter
Reducing supply voltage to 1V also does not help.
.options ABSTOL=1E06
.options RELTOL=0.1
.options GMIN=1E03
.options ITL1=1000
.options ITL2= 500
   Updated   
See below the modifications that I had done so far which do not help in DC sweep analysis convergence.

Advertisment

15th January 2019, 10:30 #12
 Join Date
 Nov 2013
 Posts
 611
 Helped
 148 / 148
 Points
 4,048
 Level
 14
Re: dc sweep convergence issue for cmos inverter
Hmm, reltol shouldn't be higher than 0.003, that is not good. But I think you should start to characterize those transistors separately. Maybe you will be smarter with that. It shouldn't be so a complicated circuit.
"Try SCE to AUX." /John Aaron/

17th January 2019, 07:06 #13
 Join Date
 Feb 2016
 Posts
 460
 Helped
 1 / 1
 Points
 2,500
 Level
 11
Re: dc sweep convergence issue for cmos inverter
DC Sweep convergence problem solved using this solution
+ Post New Thread
Please login