I have seen that the native 3v3 nfet has no model. Has this been fixed in more recent versions of skywater130?

It has a model. It's in

sky130A/libs.ref/sky130_fd_pr/spice/sky130_fd_pr__nfet_03v3_nvt.pm3.spice

in the installed PDK. It has always been there.

I have tried using the native mos toaday and spice didn't find a model for it. Do i have to do something in particular for it to work?

No. I was simulating a circuit with the

nfet_03v3_nvt

just a few days ago. The standard

.lib

statement should include the model. Are you doing this from xschem? How is your testbench set up to include the model files?

Thank you very much! I think the lengths and widths were the problem.

@Tim Edwards Continuous models are a great milestone, getting rid of W / L boundary discontinuities that are annoying, expecially in optimization algorithms. My questions: • Do you plan to set up an environmental variable to tell if Continuous or Binned model sets are to be used? (similarly to already existing PDK_ROOT and PDK variables) • Are the two model sets interchangeable? Or something must be changed in the circuit netlist? On xschem side just the SKYWATER_MODELS variable needs to be set correctly to use continuous or binned models without (hopefully) any further editing on testbenches.

@Stefan Schippers: The model sets are interchangeable. The way I have it currently set up, the old models are in

sky130A/libs.tech/ngspice

while the new ones are in

sky130A/libs.tech/combined

("combined" meaning a combination of the new continuous-valued models and the old models for all the devices that were not part of the continuous-valued set; e.g., the bipolar transistors are still the old models and still valid only for the specific layouts). The models in the

combined

path are largely self-contained inside that path, and don't include model files from

sky130A/libs.ref/sky130_fd_pr

(except, as just mentioned, the devices that weren't in the set of continuous-valued models). The models in the

libs.ref/sky130_fd_pr

path are all the old discrete-valued models. The bottom line is that switching between them is (or should be---as I said, there are a few errors that need to be fixed) simply a matter of changing

ngspice

to

combined

in the path name. The implementation is largely up to you based on what you think works best within xschem; you can either change

SKYWATER_MODELS

based on another setting, or have another variable name for the path to the continuous-valued models.

Ok, thank you for the explanation. I think I will redefine SKYWATER_MODELS based on some other setting (either an explicit xschemrc setting or an environment variable) to point to the right models. This allows to re-simulate old designs with the new models without changing the testbenches (Using another variable requires a change, albeit minimal).

I am trying to creat a monte carlo testbench but the 'mc' corners produces this error. It is similar to the error i got for the native NFET that didn't have the right W/L. Is there a way to fix this? And I have another question. Is there a way to sweep corners?

@Tim Edwards I have rebuilt and installed open_pdks but i see no combined/ directory for the continuous models. I ran a a

make veryclean

followed by a

./configure --enable-gf180mcu-pdk --prefix=/home/schippes

,

make

and

make install

. Do I need to add some options to configure? The git log of the sources show that installation of combined should be done. (commit cbfa592c66d3331d59cce58b6b553858a55a0137)

@Stefan Schippers: The continuous models are part of the sky130 PDK, not the GF180 PDK.

@Tim Edwards Oh so when I specify

--enable-gf180mcu-pdk

in the configure script only gf180mcu will be installed. I thought sky130 was always installed. So I will try again also with

--enable-sky130-pdk

@Stefan Schippers: That might have been the default at some time, but currently there are no "default" enabled PDKs, and each one you want to generate needs an

--enable-*

entry.