Could I get some help with a spice simulation? I h...
# analog-design
Could I get some help with a spice simulation? I have extracted a netlist from a small design hardened with OpenLANE. Now I want to measure the maximum current it draws in one clock cycle. I've put my work so far in this repo:
@Matt Venn when simulating a subcircuit in spice you should at the very least connect input nodes (usually landing to gates of MOS transistors) to something, like '0', 'GND', 'VGND' (for low level) or 'VPWR' (your VCC level) for high level. Output nodes of a subcircuit can be left unconnected. An unconnected mos gate usually leads to a singular matrix. A simulator can not find a DC solution for that node voltage. While a digital simulator simply assigns 'X' (or 'U' ) to such nodes an analog transistor level simulator needs to be able to find a numerical solution for these voltage values.
@Matt Venn for the missing res_generic_po this is a missing model. I got past this error by replacing the tier cell as follows:
.subckt sky130_fd_sc_hd__conb_1 LO HI VPB VNB VGND VPWR
R0 HI VPWR 0.01
R1 VGND LO 0.01
@mehdi solution to use a voltage source might be even better :
.subckt sky130_fd_sc_hd__conb_1 LO HI VPB VNB VGND VPWR
@Matt Venn First of all disregard my first post: ngspice is able to add (low) conductances to gnd to floating gate nodes to avoid singularities. Unfortunately i can not edit or delete that post. if i understand correctly you want to set the 'Vactive' input node to logic level low (0V). The correct syntax is the following:
VVactive Vactive 0 0
instead of:
Vactive VGND 0 0
the above just creates another voltage source on the VGND node that is paralled with the other one:
Vgnd VGND 0 0
a loop of voltage sources creates a singular matrix. This fix allows me to simulate your design:
reducing .tran step to 1p eliminates numerical oscillations in waveform:
👍 1
@Matt Venn your wrapped_seven_segment.spice contains just decap cells (and the above mentioned tier cell) current is extremely low as there is no cmos circuitry inside it ...
Copy code
XFILLER_94_361 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_67_586 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_27_428 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_82_556 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_52_18 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_22_166 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_77_317 VPWR VGND VPWR VGND sky130_fd_sc_hd__decap_8
XFILLER_77_306 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_4
XFILLER_58_520 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_73_501 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_4
XFILLER_45_269 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_26_483 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_60_239 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_9_159 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
XFILLER_3_89 VPWR VGND VPWR VGND sky130_fd_sc_hd__decap_8
XFILLER_95_147 VGND VPWR VPWR VGND sky130_fd_sc_hd__decap_12
X_1270_ _1404_/A _1270_/HI VPWR VGND VGND VPWR sky130_fd_sc_hd__conb_1
Thanks so much Stefan! I still make such rookie mistakes with spice.
Yes I deleted most of the contents of the model to make iteration faster.
The full model is also in the repo with a .complete extension
I'll check it myself later
OK, I've made those changes, and now I do get a result, but it's just a flat line
I still get a lot of these errors:
I pushed your suggested fixes to the repo. Could you pull and run on your side? I think maybe I have a library setup issue
though, I have done other simulations of standard cells successfully
@Matt Venn trying now...
@Matt Venn i am simulating your testbench, • I commented the
subcircuit definition in
, since you are correctly including the modified
version. • Ensure you have a
file in the directory where you launch ngspice (or in your home directory) with the following one-liner in it:
set ngbehavior=hs
. This sets the right compatibility mode for library parsing (hspice like) and also correctly handle the
option. • For some reason the antenna subcircuit incorrectly netlists the diode as a subcircuit:
Copy code
.subckt sky130_fd_sc_hd__diode_2 DIODE VGND VPWR VPB VNB
X0 VNB DIODE sky130_fd_pr__diode_pw2nd_05v5 area=4.347e+11p
You need to replace the 'X0' with 'D0':
Copy code
.subckt sky130_fd_sc_hd__diode_2 DIODE VGND VPWR VPB VNB
D0 VNB DIODE sky130_fd_pr__diode_pw2nd_05v5 area=4.347e+11p
With these changes ngspice loads the netlist without errors (it prints some warning about unrecognized parameters in antenna diode model, but that is not critical at all). It is still running, will post the results (if any) asap.
@Matt Venn at the end ngspice was unable to find an initial solution for the transient simulation:
Copy code
Trying gmin =   1.0000E-12 Note: One successful gmin step
Note: One successful source step
Supplies reduced to   0.1000% Warning: singular matrix:  check nodes la_data_in[6] and la_data_in[6]

Supplies reduced to   0.0000% Warning: singular matrix:  check nodes la_data_in[6] and la_data_in[6]

Warning: source stepping failed

Transient solution failed -
this is probably because there are so many undriven input nodes.... Try to insert the required input node drivers by using a script, for example: ... ... vla_data_in[6] la_data_in[6] 0 0 vla_data_in[7] la_data_in[7] 0 0 ... ... I don't know what are the best values (low or high) for these inputs...
Mine gets killed after the system runs out of memory (24GB)
I reduced sim time to 500p with resolution of 1p and that doesn't help
I've made the changes you suggested, added a python script to generate unused inputs and pushed
still unable to simulate due to running out of ram.
@Matt Venn what version of ngspice are you using? i have this, compiled from the pre-master ngspice git branch:
Copy code
** ngspice-34+ : Circuit level simulation program
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2020, The ngspice team.
** Please get your ngspice manual from <>
** Please file your bug-reports at <>
** Creation Date: Mon Feb 15 18:29:32 UTC 2021
some time ago a fix was made to reduce memory consumption, for some reason a mos model was loaded in memory for every mos instance, while ideally one mos model should be loaded per transistor type. This makes a huge difference in some cases. ngspic euses lot of ram on skywater pdk. this is a problem both for ngspice and the way the pdk is set up, however i have only 4GB of physical ram and the simulation process never went above 1GB virtual ram, which is still a lot but manageable.
27! 😬😬
ok so the advice is to update ngspice from sources,:D
Ok will fo
Btw do you know how to just do a simple DC current measurement?
@Matt Venn i think the most straightforward way is to insert following instruction into your control section: measure tran avg_current AVG i(Vdd) from=0 to=2n you can also insert it outside of the control block, by adding a dot: .measure tran avg_current AVG i(Vdd) from=0 to=2n where: • avg_curent is a tag to be used in the output printout • AVG is the operator (average in this case) • i(Vdd) is the variable (in this case current thru Vdd) • from and to set the time interval.
Thanks Stefan.
I've updated to 34 now
and getting a lot of these:
crss fingers 🙂
oh thats weird...
Try to comment out the includes for
resistor.spice, wrapped_seven_segment.spice.complete, inputs.spice,
all the
instance lines, add this line:
X0  VPWR  VPWR  0  0  sky130_fd_pr__nfet_01v8 ad=0p pd=0u as=0p ps=0u w=650000u l=150000u
This adds a single nmos transistor with gate and drain connected to power. Try to simulate this. If that fails there is something fundamentally broken .
I've just tried one of my other simulations and that works fine
so I'll try to work out the difference
Just to be sure, comment these: .inc "./sky130_fd_pr/cells/pfet_01v8_hvt/sky130_fd_pr__pfet_01v8_hvt__tt.pm3.spice" .inc "./sky130_fd_pr/cells/nfet_01v8/sky130_fd_pr__nfet_01v8__tt.pm3.spice" .inc "./sky130_fd_pr/models/sky130_fd_pr__model__r+c.model.spice" The ./sky130_fd_pr/models/sky130.lib.spice should be enough. I don't think this will change the result but just to be sure...
yes with all those commented out it doesn't have all theose errors
some of the above includes are supposed to be called from the top level .lib file. may be including from a global context clashes some definitions
then I try to simulate again the 7seg and get model not found errors again
I've had that before with scale issues
I wonder if the extracted spice scale is not matching
i have created a sky130.lib_tt.spice in the models/ directory of the skywater-pdk that looks like this: (it contains only the tt corner to speed up parsing). i only do a
.lib "/path/to/pdk/models/sky130.lib_tt.spice" tt
to get all models recognized...
Copy code
******* SkyWater sky130 model library *********

* Typical corner (tt)
.lib tt
.include "../cells/nfet_01v8/sky130_fd_pr__nfet_01v8__tt.corner.spice"
.include "../cells/nfet_01v8_lvt/sky130_fd_pr__nfet_01v8_lvt__tt.corner.spice"
.include "../cells/pfet_01v8/sky130_fd_pr__pfet_01v8__tt.corner.spice"
.include "../cells/nfet_03v3_nvt/sky130_fd_pr__nfet_03v3_nvt__tt.corner.spice"
.include "../cells/nfet_05v0_nvt/sky130_fd_pr__nfet_05v0_nvt__tt.corner.spice"
.include "../cells/esd_nfet_01v8/sky130_fd_pr__esd_nfet_01v8__tt.corner.spice"
.include "../cells/pfet_01v8_lvt/sky130_fd_pr__pfet_01v8_lvt__tt.corner.spice"
.include "../cells/pfet_01v8_hvt/sky130_fd_pr__pfet_01v8_hvt__tt.corner.spice"
.include "../cells/esd_pfet_g5v0d10v5/sky130_fd_pr__esd_pfet_g5v0d10v5__tt.corner.spice"
.include "../cells/pfet_g5v0d10v5/sky130_fd_pr__pfet_g5v0d10v5__tt.corner.spice"
.include "../cells/pfet_g5v0d16v0/sky130_fd_pr__pfet_g5v0d16v0__tt.corner.spice"
.include "../cells/nfet_g5v0d10v5/sky130_fd_pr__nfet_g5v0d10v5__tt.corner.spice"
.include "../cells/nfet_g5v0d16v0/sky130_fd_pr__nfet_g5v0d16v0__tt_discrete.corner.spice"
.include "../cells/esd_nfet_g5v0d10v5/sky130_fd_pr__esd_nfet_g5v0d10v5__tt.corner.spice"
.include "corners/tt/nonfet.spice"
* Mismatch parameters
.include "../cells/nfet_01v8/sky130_fd_pr__nfet_01v8__mismatch.corner.spice"
.include "../cells/pfet_01v8/sky130_fd_pr__pfet_01v8__mismatch.corner.spice"
.include "../cells/nfet_01v8_lvt/sky130_fd_pr__nfet_01v8_lvt__mismatch.corner.spice"
.include "../cells/pfet_01v8_lvt/sky130_fd_pr__pfet_01v8_lvt__mismatch.corner.spice"
.include "../cells/pfet_01v8_hvt/sky130_fd_pr__pfet_01v8_hvt__mismatch.corner.spice"
.include "../cells/nfet_g5v0d10v5/sky130_fd_pr__nfet_g5v0d10v5__mismatch.corner.spice"
.include "../cells/pfet_g5v0d10v5/sky130_fd_pr__pfet_g5v0d10v5__mismatch.corner.spice"
.include "../cells/nfet_05v0_nvt/sky130_fd_pr__nfet_05v0_nvt__mismatch.corner.spice"
.include "../cells/nfet_03v3_nvt/sky130_fd_pr__nfet_03v3_nvt__mismatch.corner.spice"
* Resistor/Capacitor
.include "r+c/res_typical__cap_typical.spice"
.include "r+c/res_typical__cap_typical__lin.spice"
* Special cells
.include "corners/tt/specialized_cells.spice"
* All models
.include "all.spice"
* Corner
.include "corners/tt/rf.spice"
since the top .lib file uses relative paths (../cells/) you should call a .lib file that is placed inside models/
tried that, same error messages as when I include the normal lib
re my scale idea, I don't think that's it because the scale of the fets dimensions looks the same as the simulations I have that work
could you do a fresh clone of my repo with --recursive to get the models as I have them. And tell me if you get the same issue now I'm on ngspice34?
hash is c98a3fc64cebe002b19c8cc816db0d0b7828bea7
so it is a git clone --recursive ?
you probably did not checkin inputs.spice, it is missing
make should make it
make sim
ah , sorry... doing
yes, with your git cloned i get the same unfound models
now trying with my local skywater pdk
yes with a single replacement of your .lib with my .lib: .lib "/home/schippes/skywater-pdk/libraries/sky130_fd_pr/latest/models/sky130.lib_tt.spice" tt simulation goes straight to the end. You should comment out the sky130_fd_sc_hd__conb_1 subckt since it is overidden by the resistor.spice include. Just to remove a warning
so there are some differences in the pdk files
thanks a lot Stefan
I think this will get me there. I'm on my laptop with an outdated pdk, so I'll check this all on my work pc tomorrow and use your include file
looks like that will speed up sim too
try to get a new fresh copy of the pdk, i think that will fix the boat
yeah, I'm trying v0.9 openlane and have the relevent pdk so will check it tmorrow and post back
by experience i know everything is rapidly evolving, a 2 months old is considered old here, hehehe, while 2 months is in no case enough to get any software packaged for a linux distro --> so any packaged eda software is outdated by definition 🙂
🤣 1
I hve crushed my head against the pdk many times while creating the xschem symbol libraries for skywater. It's a slowly convergent trial & error & refine process...
since there are many actors involved, the pdk itself, the simulator, xschem, and many other tools. Not to mention a digital flow 🙂 i think you had your pile of issues...
Yep. But gratifying to get results!
💪 1
I don't have anything in skywater-pdk/libraries/sky130_fd_pr/latest/
I've installed the pdk with openlane, by running make pdk
is there something else I have to do to get the models?
no whoops, I was looking in the wrong lib
I needed to do git submodule update libraries/sky130_fd_pr/latest/ in skywater pdk
Thanks Stefan!
have updated my repo with instructions