That takes a lot longer to load though it seems

instead of ~2 seconds, maybe 15 seconds

That is true and an annoying downside. But at least you know you've got everything defined as the simulations get larger and larger

But yeah, there's definitely an argument that the quicker loading time is worth it

Right

Maybe ngspice can precompile them somehow

Yea I did whatever the spice files in the test folder was doing, which is the corners file indeed. And as pointed out, they are subcircuits rather than models, which also threw me off for a minute.

I can't get it to work though, @User do you have your .spice file available?

Mine becomes:

**.subckt testar
V.10MHz in GND pulse(0 3 2ns 2ns 2ns 50ns 100ns)
C1 in filter_out 1p m=1
R1 filter_out GND 10k m=1
M1 inv_out in vcc vcc sky130_fd_pr__pfet_01v8 w=1 l=1 mult=1
M2 inv_out in GND GND sky130_fd_pr__nfet_01v8__model.0 w=5u l=0.18u m=1
V.3V vcc GND pwl 0 3
**** begin user architecture code


.lib /home/bluecmd/eda/sky130_fd_pr/models/sky130.lib.spice tt
.tran 0.1n 1u uic
.save all

**** end user architecture code
**.ends
.GLOBAL GND
.end

ignore the nfet one, it's the pfet I am trying to get to work

even if I move the .lib to the top it doesn't seem to change anything, the output is:

warning, can't find model sky130_fd_pr__pfet_01v8
warning, can't find model sky130_fd_pr__nfet_01v8__model.0

ngspice stopped due to error, no simulation run!

ERROR: fatal error in ngspice, exit(1)

Circuit: **.subckt testar

Scale set
Error on line 5 :
  m1 inv_out in vcc vcc sky130_fd_pr__pfet_01v8 w=1 l=1 mult=1
could not find a valid modelname
Error on line 6 :
  m2 inv_out in 0 0 sky130_fd_pr__nfet_01v8__model.0 w=5u l=0.18u m=1
could not find a valid modelname

** ngspice exited with error code 0 **
Press enter to close

your FETs have M prefix, that needs to be an X for a subcircuit

Is that W L available in the bin?

also the scale means that things are expressed in microns so don't need a u suffix

Great, thanks! I didn't know the prefix was important

I only did nmos so far haha

Literally just skywater-pdk/libraries/sky130_fd_pr/latest/cells/nfet_01v8/tests/sky130_fd_pr__nfet_01v8__nfet_vth.spice

skywater-pdk/libraries/sky130_fd_pr/latest/cells/pfet_01v8/tests/sky130_fd_pr__pfet_01v8__pfet_vth.spice includes a different file though...

image.png

It wooorks!

Ok, first draft is available at https://github.com/bluecmd/learn-sky130/blob/main/schematic/xschem/getting-started.md

It's mostly command dumps and some introduction text but should be enough for somebody to hopefully get to the point where I am at right now.

@User: The very important thing to know about the SkyWater models is that in the hierarchy they define

.option scale=1E-6

. This causes all of the dimension units to be interpreted as microns. Therefore

w=5u

is no longer valid and should be changed to

w=5

; likewise with all other length units (area units correspondingly get multiplied up by 1e12). This is a horrible practice and I wish they had not done that inside the model files, but I have looked at what it would take to pull it out, and it's not pretty. Looks like a lot of hard work to track down every equation involving a dimension.

@User Thanks for this reminder. I was tripped up by this early on. I thought I got it but now I have my doubts because the standard cell models look like this:

.subckt sky130_fd_sc_hvl__inv_1 A VGND VNB VPB VPWR Y
X0 VPWR A Y VPB sky130_fd_pr__pfet_g5v0d10v5 w=1.5e+06u l=500000u
X1 VGND A Y VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=500000u
.ends

Where they are still using the “u” suffix. I reflexively copied from this model when adapting the OSU cells which are posted with the M cards instead of the X cards in the earlier style. Should I be doing w=1.5 l=0.5 ? As you noted it is a tricky to remove scale= because the scaling is only done on values that are related to length (e.g. lengths, widths and areas).

While discussing gotchas...

@User: This comes from magic---magic does not anticipate the "scale" option being used in the models and so generates units in the output with suffixes "u", "n", "p" as appropriate. So to work around that, I was forced to multiply up the units by 1E6; e.g., "1.5E06u" in SPICE == "1.5" because 1E06 and "u" cancel out.

@User: "As you noted it is a tricky to remove scale= because the scaling is only done on values that are related to length (e.g. lengths, widths and areas)." --- It's even trickier than that, because the scaling is applied before the model is called, so values of parameters inside the model are still in SI units. Values that are not measurements but related in some way, like capacitance per unit area, do not get the scaling. The worst problems are in the resistors, where they compute non-scaled parameters from scaled values; e.g.,

rhead0 = 188.2 / (weff-0.0672*max(0.69-w,0)+1.41)

. I cannot think of any reasonable automated way to determine how to convert this from scaled units to unscaled units.

What kind of performance can you expect from this technology? I made an inverter in spice and did an AC analysis, but I seem to be getting a few hundred MHz max. I set my supply to 1.8V and picked the LVT devices, and then played around a bit with M and W/L from the spreadsheet bins. (I seem to remember in uni we used W/L in the dozens with a bunch of fingers) And that's just an inverter... is it feasible at all to build a more complex circuit with a bandwidth of 500MHz?

I'm currently laying out a frequency divider that's good for 10 GHz, even at ss corner and 125 degC. Not tested higher yet as that's all I need for current plans - the 'dime' amateur radio satellite band. Once we get started with on die inductors then even higher frequencies will be possible. So you can definitely get a bit of speed out of the process, but you need to design for it

@User You can make a 4GHz ring oscillator for a VCO in 130nm using differential amplifiers with balanced loads https://ieeexplore.ieee.org/document/5401347