#450 Error simulating some MOSFETs in my own xschem but successful in open_pdk xschem_tests Issue created by 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? RTimothyEdwards/open_pdks

Hello together. I am facing a bug in magic. When instantiating my design via

make user_project_wrapper

in

[STEP 26] [INFO]: Running Magic Spice Export from GDS

it gets stuck and runs forever. The

26-gds.spice.log

log says:

[...]
Extracting sky130_fd_sc_hd__o221ai_2 into sky130_fd_sc_hd__o221ai_2.ext:
Extracting sky130_fd_sc_hd__o2111a_2 into sky130_fd_sc_hd__o2111a_2.ext:
Extracting sky130_fd_sc_hd__a2111oi_2 into sky130_fd_sc_hd__a2111oi_2.ext:
Extracting mkWrapDexieAndScoooter into mkWrapDexieAndScoooter.ext:
Created database crash recovery file /tmp//MAG1352.8GQ5Lx
Extracting user_project_wrapper into user_project_wrapper.ext:

And the

user_project_wrapper.ext

says:

[...]
node "io_out[37]" 0 0 -960 19260 m3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[33]" 0 0 244066 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[80]" 0 0 410770 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[123]" 0 0 563214 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "io_out[30]" 0 0 -960 358308 m3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[74]" 0 0 389426 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "io_out[33]" 0 0 -960 201772 m3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[9]" 0 0 158874 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[114]" 0 0 531290 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
node "la_data_out[36]" 0 0 254646 -960 m2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Notice the incomplete last line, which does not change (at least) for hours. Any idea would be appreciated. Is it because I did not connect all ILA signals? I only connected the first 6 ILA signals. Info: We are using EF_SRAM directly instantiated without the wishbone wrapper. I will leave it running for the next few hours. Maybe it will recover.

Hello, I have a weird problem when I run my Precheck. The magicDRC gave me 66,333 errors, but they do not correspond to the layout. I'll show you a few examples. One DRC error says "under HVI or LV nwell," but I don't have this kind of layer. The DRC provided by KLayout says I have 400 errors in total, and they correspond to something

Hello, I have 3 separate circuits that interface with wire bond pads, I'm struggling to pass LVS checks for each individually. I'm using the

test_io.gds

shared by @Tim Edwards , eventually I'd like to get multiples of the 3 circuits and bond pads in the user area, but have one instance of each and 14 total pads. I've attached the lvs report as well as the extracted spice netlist from my gds. Additionally, I'm getting a

Klayout Metal Minimum Clear Area Density

violation that I've not seen before, looking at the xml report in klayout shows messages like

0.4 min li1 ca pattern density

, or

0.4 min m3 ca pattern density

, as well as

0.4 min m4 ca pattern density, m4 ca density is -38.36204247422786

, how are these issues best resolved, how is the negative density to be interpreted? Thank you.

@Tim Edwards Hi, how can I obtain a high-resolution image of a layout? I want to use it for a journal paper. Thanks in advance!

Hello @Mitch Bailey @Tim Edwards i am trying to run the lvs but its getting crash could you please let me know how to fix it

Can IO analog pins be used as bidirectional? I want to use this pin as both input and output in post silicon

Hello people, I'm making a via array with DCellInstArray. I don't know how to be able to remote some of those vias. I think I should flatten the array but not sure how. The hierarchy is

TOP:
- res_dev
- via_stack_dev

nmos used as switches for resistance trimming in bgr circuits cause large output voltage variations with temperature. Such variations would not be there if the trimming circuit is not included. May I please have suggestions.

If I write a patch to change caravel to caravan (i.e. remove some of the extra MPRJ I/O and put in the analog pads instead) and have my Makefile run that patch at the appropriate times (like setup) will I be able to use such. I.e. will a human intervene and say no caravel, no OpenMPW?