@Tim Edwards I have a question from a developer. Is it possible to do a 'light' open_pdks install, containing only the spice models (I am referring to sky130) and the standard cell extracted netlists? So no liberty files compiling and no layout data.

If this is from Dietmar Warning, then the answer is that he should have been able to run the simulations on the models in the source directory, and it was my own fault that the include paths in the source repository were relative to the installed PDK and not the source PDK. He should not have to do an install at all. And I fixed the source repository a few minutes ago.

Ok, thanks. Btw I don't know why he asked to me :-)

It is, however, possible to do a "light install" by running the "configure" script as usual, then doing:

cd sky130
make tools-A
make primitives-A

That will generate only the SPICE models (the

tools-A

is not directly related but needs to be done first).

Thank you! this is useful to me too.

When you answer too many user questions, you automatically become an expert.

@Tim Edwards tomorrow I will do an update of my open_pdks install and try again the test cases on the combined models. For nfet and pfet I see some problems with the 20v0 transistors. • sky130_fd_pr__pfet_20v0_base • sky130_fd_pr__nfet_20v0_base The error signature is the usual "could not find a valid modelname"

That's odd, because the devices are part of the continuous models and there is only one "approved" layout. . . So I would have expected that to be in range. There is only a single bin for the device models:

.model sky130_fd_pr__nfet_20v0_base.0 nmos
+ lmin = 4.95e-07 lmax = 3.05e-06 wmin = 1.9995e-05 wmax = 1.0005e-03

and

.model sky130_fd_pr__nfet_20v0_base.0 nmos
+ lmin = 4.95e-07 lmax = 3.05e-06 wmin = 1.9995e-05 wmax = 0.0011

and

.model sky130_fd_pr__pfet_20v0_base.0 pmos
+ lmin = 4.95e-07 lmax = 5.05e-07 wmin = 2.9995e-05 wmax = 1.0105e-03

What device width and length is being instanced? It's not clear to me yet why the nfet 20v model appears three times in the file. . .

Ok tomorrow I will investigate. For the nfet:

L=2.95

W=29.41

mult=1

model=nfet_20v0

For the pfet:

L=0.5

W=30

nf=1 mult=1

model=pfet_20v0

@Stefan Schippers: What I found was this: The pfet model is defined with

nf=2

. For reasons I don't understand (see post below), even though your pfet_20v0 symbol has

nf=1

, that is not ending up in the netlist output, where I see:

XM6 net6 G5v0 S B sky130_fd_pr__pfet_20v0 L=0.5 W=30 m=1

That causes the

nf=2

to be in effect, so the individual device width is 15um, which is below the minimum limit (same problem applies to the nfet_20v0 devices). The 20V device layouts are drawn as two fingers sharing the drain, which might be the only legal configuration. So there is one minor issue, which is that the symbol should probably not define

nf

at all, but it should at least be assuming

nf=2

for all 20V devices; and then there is the other issue in which the

nf

value doesn't end up in the netlist even when it is in the symbol definition.

@Tim Edwards before digging into the problems of the 20v0 FETs i was trying to update magic and open_pdks. The master branch of git://opencircuitdesign.com/open_pdks shows last commit was done on Jan. 14 (commit

30656fcd54fb8ba48caf1701f5b01b89f3f0c4fc

). Is that correct? if so, no need to update anything?

I have made a few updates to the underlying repositories, but yes, Jan. 14 was the last update of open_pdks.

@Tim Edwards I have fixed the 20v0 fets, and all related testcases are running with meaningful results. What still remains are some standard cells with the

W=0.36

nfet_01v8* transistors, while the minimum W is

0.42

in the "combined" models.

Error on line:
  m.x2.x2.x7.msky130_fd_pr__nfet_01v8 x2.x2.a_448_47# x2.x2.a_27_47# x2.x2.a_543_47# vss x2.x2.x7.nshort_model x2.x2.x7.l= x2.x2.x7.  1.500000000000000e-01   w=    3.600000000000000e-01     ad=    0.000000000000000e+00     as=    0.000000000000000e+00     pd=    0.000000000000000e+00     ps=    0.000000000000000e+00     nrd=    3.888888888888890e-01     nrs=    3.888888888888890e-01     sa=    0.000000000000000e+00     sb=    0.000000000000000e+00     sd=    0.000000000000000e+00     nf=    1.000000000000000e+00     delvto=    0.000000000000000e+00   
could not find a valid modelname
    Simulation interrupted due to error!

like in this flop:

.subckt sky130_fd_sc_hd__dfrtp_1 CLK D RESET_B VGND VNB VPB VPWR Q
...
...
X7 a_448_47# a_27_47# a_543_47# VNB sky130_fd_pr__nfet_01v8 w=360000u l=150000u
...
...
.ends

Yes, I'm fully aware of that issue; it's just going to be a royal pain to integrate the single bin from the discrete models by splicing it onto the end of the continuous models (and then do that for all corner models, monte carlo models, etc.). At least it's only a few devices.