open-source-silicon.dev

<@U018459959C>:  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.

Right, it seemed quite strange to me - but I think I didn't end up having any 5u or something like that, I think all is w=1 l=1 m=1 and so on - no?

I posted before I saw several of the most recent posts, so I'm not exactly sure what state your simulation is in now.  Generally speaking, the ngspice error "could not find a valid modelname" means that the W and L don't fit in the lmin...lmax or wmin...wmax range of any model bin.  This can be because (1) incorrectly dealing with the .option scale thing, (2) specifying nf !=1 due to the ngspice bug, or (3) failing to match the W and L ranges of the micro-binned models, which have gaps in the ranges everywhere.

By "micro-binning" I mean that SkyWater has modeled only specific W and L devices that they characterized on some test wafer, and they do not have models that are continuous over W and L.  Some people with access to the original SkyWater data under NDA were able to show that if you remove the lmin...lmax and wmin...wmax limits, then some of the models are extremely and weirdly discontinous over W and L.  Outside of the specific points where devices were modeled, the models cannot be trusted (most are reasonable but it would be a vast effort to find out exactly which ones aren't).