@User yes ok

@User: I see the output says "Scale set". Is that from SkyWater's files, or did you set the scale option yourself? "could not find a valid modelname" is a typical error when the scale has been set incorrectly.

@User: But looking close at the error line, I think it is just that you have L set to 0.473 and W set to 0.87 and they probably do not correspond to existing bins for the device model.

I have sent my spice files in a sub-thread.

I have some dinner related tasks now, will be back in 1h.

@User: The closest model pins for the pFET HVT is L = 0.5um and W = 0.82um.

"bin", not "pins". . .

@User @User the offending standard cell is the first one in the inverter.spice netlist, it's a decap cell, containing p an n fets (p with gate to gnd, n with gate to vpwr) :

.subckt sky130_fd_sc_hd__decap_12 VGND VNB VPB VPWR
X0 VPWR VGND VPWR VPB sky130_fd_pr__pfet_01v8_hvt w=870000u l=4.73e+06u
X1 VGND VPWR VGND VNB sky130_fd_pr__nfet_01v8 w=550000u l=4.73e+06u
.ends

since these do not take any parameter either the standard cell is wrong or the model binning is wrong.

@User: I think the binning is wrong. Looks like they have the right widths, e.g., there are bins for W=0.55um on the nFET, and there are long devices that sort of match the decap cells except that the lengths are 1, 2, 4, and 8 microns. Maybe the bins on those devices should be expanded to cover the range that includes the physical layouts in the standard cells. Issues related to modeling problems outside of the bins shouldn't matter much for devices used as decap.

@User: My suggestion is to modify the file

sky130_fd_pr__nfet_01v8.pm3.spice

in the model files, find the nearest device bins, and change the values of "lmin" and/or "lmax" to include the actual length of the device. I have given a bit more detail about this in the github issue tracker for skywater-pdk, issue #228.

Thanks @User and @User, I went through spice files and located the offending lines, so I think I should be able to do the suggested changes. But it will probably have to wait till tomorrow.

I've not been following this channel, can someone tell me what is the status of the analogue cell library?

@User this can be solved by editing file (example for tt corner):

sky130_fd_pr__pfet_01v8_hvt__tt.corner.spice

and letting it include

sky130_fd_pr__pfet_01v8_hvt__tt.pm3.spice

instead of

sky130_fd_pr__pfet_01v8_hvt.pm3.spice

the default included file has 'point-size' binning , as it defines points instead of regions. the

_tt.pm3.spice

file defines reasonable continuous regions. This change is already done for nfet_01v8_lvt if this patch is applied (fixes the temp->temper and tempo coefficients issues in resistors, contribution from @User). Curious enough is the fact that for other transistors (example: pfet_01v8_lvt) this

_tt.pm3.spice

is already the default included file. I can update the patch file to make the change for these p_hvt transistors. I usually work with this patched version of the spice models as i was too much bored of these error messages. Needless to say, it must be verified if the accuracy is acceptable when using these binned models outside their 'point-sized' existence regions.

@User: A patch file update would be good. I don't think that the original patch file has been applied to the repo yet.

@everything is already there, it looks to me it was just a missing change already planned.

@User, I followed your instructions about modifying the last line

.include

in

sky130_fd_pr__pfet_01v8_hvt__tt.corner.spice

, then I got a similar error for the

nfet

in the same

decap

. So I made the same change in

cells/nfet_01v8/sky130_fd_pr__nfet_01v8__tt.corner.spice

and this cleared all similar errors.I still have to modify the input stimuli before getting a proper simulation, so I can't claim full success yet.

@User the inverter instance in your 'inverter.spice' file has wrong node order: (sky130 stdcells have input(s) power nodes output(s) ), here the original and the correct order * X_0_ in out VGND VGND VPWR VPWR sky130_fd_sc_hd__inv_8 X_0_ in VGND VGND VPWR VPWR out sky130_fd_sc_hd__inv_8

@User i have also replaced your 'a5' stimuli with a pulse gen:

clock
* a5 1 8 var_clock
* .model var_clock d_osc(cntl_array = [-2 -1 1 2]
* +                      freq_array = [1e3 1e3 10e3 10e3]
* +                      duty_cycle = 0.4
* +                      init_phase = 180.0
* +                      rise_delay = 10e-9
* +                      fall_delay = 8e-9)

** stefan added a pulse generator don't know much about above syntax and it does not appear to connect to "in" node
vpulse in 0 pulse 0 1.8 0 1n 1n 9n 20n

@User Voila!

@User thanks for the update. Since

inverter.spice

was generated with openlane (with an updated version of skywater-pdk to connect to missing ports for fill/dcap cells, see https://github.com/efabless/openlane/issues/84) I would assume there is another bug in the PDK, perhaps already fixed an an even newer version. But now it's too late in the evening for me to debug and report it further. It will wait for tomorrow.

@User @User following patch includes latest @User patches and fixes (well, removes ngspice errors), binning errors for

nfet_01v8

and

pfet_01v8_lvt

. This patch is applied to the

skywater-pdk/libraries/sky130_fd_pr

tree (sky130_fd_pr supposed to contain

latest

directory) What i usually do is to

cp -a sky130_fd_pr  sky130_fd_pr_ngspice

to avoid clobbering the original tree, then i descend into

sky130_fd_pr_ngspice

and apply the patch:

patch -p1 <patch_file

The patch file fixes all 5 process corners (ss sf fs ff tt).

Can people check if they can see the sky130_fd_io library at https://foss-eda-tools.googlesource.com/ ?

got i

t

@User You mean you can see it?

yes, I can see it and I can browse into it

@User ping?

@User In https://github.com/google/skywater-pdk/issues/171#issuecomment-723493939 you said "Once this patch is applied, my ".param temp=" statements in the test SPICE netlists in sky130_fd_pr should be removed"

I can't find anything which looks like ".param temp="

There is

.param TEMP=27

?