Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

dc sweep convergence issue for cmos inverter

Status
Not open for further replies.
P

promach

Advanced Member level 4
Joined
Feb 22, 2016
Messages
1,199
Helped
2
Reputation
4
Reaction score
5
Trophy points
1,318
Activity points
11,636
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.

Jmq3V.png


Code: 
[phung@archlinux frequency_trap]$ make test_CMOS_Inverter.net
gnetlist -L ../.. -g spice-noqsi 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

ngspice-30 : Circuit level simulation program
The U. C. Berkeley CAD Group
Copyright 1985-1994, Regents of the University of California.
Please get your ngspice manual from [url]http://ngspice.sourceforge.net/docs.html[/url]
Please file your bug-reports at [url]http://ngspice.sourceforge.net/bugrep.html[/url]
Creation Date: Thu Jan 3 04:39:51 UTC 2019

Circuit: * gnetlist -l ../.. -g spice-noqsi -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.080796e-03
@m.x1.m2[gds] = 5.094415e-03
@m.x1.m2[gm] = 1.145951e-03
cout = 2.997462e+00
v_ip_out#branch = -2.99746e-11
vd#branch = -1.71460e-03
vdd = 3.300000e+00
vin = 1.650000e+00
vin#branch = 0.000000e+00
vout = 2.997462e+00
vs#branch = 1.714603e-03
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 spice-noqsi -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 spice-noqsi -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 ->

test_CMOS_Inverter.net

Code: 
* gnetlist -L ../.. -g spice-noqsi -o test_CMOS_Inverter.net test_CMOS_Inverter.sch
* SPICE file generated by spice-noqsi 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

CMOS_Inverter.net

Code: 
* gnetlist -L ../.. -g spice-noqsi -o CMOS_Inverter.net CMOS_Inverter.sch
* SPICE file generated by spice-noqsi 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
 

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"?).
 

based on MOSFET models with only default / unknown parameters
Click to expand...

Did you check my CMOS_Inverter.net ?

Cout = 3 -Farads- in the run log
Click to expand...

Where did you get this ? I can only see Cout = 1n
 

promach said:
Did you check my CMOS_Inverter.net ?
Click to expand...

Yes, and nowhere in what's shown are any model params declared.
Only geometric device-card arguments.


Where did you get this ? I can only see Cout = 1n
Click to expand...

...
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.080796e-03
@m.x1.m2[gds] = 5.094415e-03
@m.x1.m2[gm] = 1.145951e-03
cout = 2.997462e+00
....
 

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.080796e-03
@m.x1.m2[gds] = 5.094415e-03
@m.x1.m2[gm] = 1.145951e-03
cout = 2.997462e+00
Click to expand...

This cout is a voltage node result for operating point analysis. So, it means 2.997V across the capacitor cout

Yes, and nowhere in what's shown are any model params declared.
Only geometric device-card arguments.
Click to expand...

What do you expect from a modelcard user (which is me) to include in the circuit design besides W and L of the device ?
 

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.
 

You get the node voltage of the output capacitor and you have convergence issue?
Click to expand...

The node voltage of the output capacitor is from operating point analysis. This forum thread is discussing about DC sweep analysis which is not the same as .op analysis


you can set probably relative/absolute tolerances of the solver
Click to expand...

ngspice manual states that the **broken link removed** is 1E+12, I have set it to 1E+06 as well as 1E+03 , but then this still does not help
 

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:
promach said:
What do you expect from a modelcard user (which is me) to include in the circuit design besides W and L of the device ?
Click to expand...

.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 / non-monotonicity 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
known-good model eliminates the convergence issues.
It's certainly possible to apply .model arguments which
directly cause numerical problems.
 

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.
 

Reducing supply voltage to 1V also does not help.
.options ABSTOL=1E-06
.options RELTOL=0.1
.options GMIN=1E-03
.options ITL1=1000
.options ITL2= 500
Click to expand...

I have tried setting the **broken link removed**, but it does not help too.

- - - Updated - - -

See below the modifications that I had done so far which do not help in DC sweep analysis convergence.

mUdFInJ.png
 

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.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top