Error simulating some MOSFETs in my own xschem but successful in open_pdk xschem_tests

[JacobEFO]

Hi,

I am currently battling some funky issues. I should have successfully installed all the tools, in the right manner and without errors.

What I initially did was run the open_pdk xscheem tests, running the test_nmos.sch and test_res.sch benches that both successfully run and generate results, both with sky130A and sky130B.

When I then make my own schematic with a single primitive I get some simulation issues with nfet_01v8, nfet_03v3_nvt and nfet_05v0_nvt, both in 4T and 3T models. You can see the issue below (and similarly for the other types of devices):

Warning from checkvalid: vector @m.xm1.msky130_fd_pr__nfet_0v18[ib] is not available or has zero length

and it does not generate my .raw file. If I use the nfet_20v0 I have no problems simulating whatsoever. You can see an example of the faouoeg netlist:

** sch_path: /home/jefo/MEGA/Electronics/Xschem/hello_world_desktop/nfet_01v8.sch
**.subckt nfet_01v8
Vmeas P net1 0
.save i(vmeas)
XM1 net1 net1 G G sky130_fd_pr__nfet_01v8 L=0.5 W=1 nf=1 ad='int((nf+1)/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29' pd='2*int((nf+1)/2) * (W/nf + 0.29)'
+ ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd='0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1
**** begin user architecture code

.option savecurrents
vp p 0 1.8
vg g 0 0
.control
save all
dc vp 0 1.8 0.005
write nfet_01v8.raw
.endc

.lib /home/jefo/cad/share/pdk/sky130B/libs.tech/combined/sky130.lib.spice tt
**** end user architecture code
**.ends
.end

And the successful one:

** sch_path: /home/jefo/MEGA/Electronics/Xschem/hello_world_desktop/nfet_01v8.sch
**.subckt nfet_01v8
Vmeas P net1 0
.save i(vmeas)
XM1 net1 net1 G G sky130_fd_pr__nfet_20v0 L=0.5 W=40 m=1
**** begin user architecture code

.option savecurrents
vp p 0 1.8
vg g 0 0
.control
save all
dc vp 0 1.8 0.005
write nfet_01v8.raw
.endc

.lib /home/jefo/cad/share/pdk/sky130B/libs.tech/combined/sky130.lib.spice tt
**** end user architecture code
**.ends
.end

I have tried removing all the settings for parameters such as ad etc, moving around the mult, m, nf and so forth to no avail and I am at a loss at the moment. This issue occurs both in a MacOS v.12 installation and this one on my Fedora.

One thing I noticed in the models_fet.spice-file is the definition for the 20 V NMOS looks vastly different from the failing NMOS devices as you can see below:

.subckt  sky130_fd_pr__nfet_20v0_iso d g s b sub  w=60u l=2u sa=0 sb=0 nf=2 mult=1
.subckt  sky130_fd_pr__nfet_20v0_nvt d g s b  w=60u   sa=0 sb=0 sd=0  nf=2 mult=1
.subckt  sky130_fd_pr__nfet_g5v0d16v0 d g s b mult=1
.subckt  sky130_fd_pr__nfet_g5v0d16v0_base  d g s b  mult=1
.subckt  sky130_fd_pr__nfet_20v0 d g s b  w=60u  sa=0 sb=0 sd=0  nf=2  mult=1
.subckt  sky130_fd_pr__nfet_20v0_zvt d g s b  w=60  sa=0 sb=0 sd=0  nf=2 mult=1
.subckt  sky130_fd_pr__esd_nfet_05v0_nvt d g s b mult=1
.subckt  sky130_fd_pr__nfet_01v8_esd d g s b mult=1
.subckt  sky130_fd_pr__esd_nfet_g5v0d10v5 d g s b mult=1
.subckt  sky130_fd_pr__nfet_01v8_lvt  d g s b  mult=1
.subckt  sky130_fd_pr__nfet_03v3_nvt  d g s b  mult=1
.subckt  sky130_fd_pr__nfet_05v0_nvt  d g s b  mult=1
.subckt  sky130_fd_pr__nfet_01v8  d g s b  mult=1
.subckt  sky130_fd_pr__nfet_g5v0d10v5  d g s b  mult=1
.subckt  sky130_fd_pr__pfet_g5v0d16v0 d g s b mult=1
.subckt  sky130_fd_pr__pfet_g5v0d16v0_base  d g s b  mult=1
.subckt  sky130_fd_pr__pfet_20v0 d g s b  w=50u l=2u  nf=2   sa=0 sb=0 sd=0  mult=1
.subckt  sky130_fd_pr__esd_pfet_g5v0d10v5 d g s b mult=1
.subckt  sky130_fd_pr__pfet_01v8_hvt  d g s b  mult=1
.subckt  sky130_fd_pr__pfet_01v8_lvt  d g s b  mult=1
.subckt  sky130_fd_pr__pfet_01v8  d g s b  mult=1
.subckt  sky130_fd_pr__pfet_g5v0d10v5  d g s b  mult=1

Found with rg subckt models_fet.spice in the installed location /share/pdk/sky130B/libs.tech/combined/continuous.

Can you possibly see where I go wrong here?

[StefanSchippers]

Add a remzerovec before the write instructions. This removes zero length vectors (for example some transistor body currents) before writing a raw file. I consider this a ngspice issue, since I don't understand why these vectors are not removed automatically instead of refusing to generate the output raw file.

...
...
dc vp 0 1.8 0.005
remzerovec
write nfet_01v8.raw
...
...

[JacobEFO]

This did indeed resolve the issue. Adding remzerovec was the right resolution.

Thank you very much for your assistance.