search

google / skywater-pdk

Open source process design kit for usage with SkyWater Technology Foundry's 130nm node.
https://skywater-pdk.rtfd.io
Apache License 2.0
2.95k stars 382 forks source link

Spectre-to-ngspice conversion script for monte carlo params, courtesy of Brad Minch. #309

Open RTimothyEdwards opened 3 years ago

RTimothyEdwards commented 3 years ago

The following script is provided by Brad Minch and converts the commented-out spectre statements with monte carlo parameters into something that is ngspice-compatible. The ngspice variable name "MC_SWITCH" is used to turn the behavior on (1) or off (0). I am posting the (zipped) python script for anybody who wants to play around with it. I will vet it more carefully when I start working on pull requests to sky130_fd_pr.

process_mismatch_params.zip

holvo commented 3 years ago

Would it make sense to add this to ngspice directly? It might become part of the ngspice compatibility processor (a set of functions activated by a suitable compatibility switch).

RTimothyEdwards commented 3 years ago

@holvo : I'm assuming that you mean parsing the "statistics { ... mismatch { ... } ... process { ... } }" blocks? The problem is that it was already possible to do mismatch and process monte carlo simulations in the way that the script above does it. Since it only requires setting a parameter value to turn the statistical variation on and off, it is completely compatible with ngspice and most other spice variants that I know of. The statistics {} syntax falls under the category of what I would consider "things that a commercial tool vendor did probably for the sole reason of forcing people to use their tool". Because the statistics {} block only describes which variables need to be varied, it does not indicate whether or not to apply the variation. So you would need some additional method to enable/disable the variation.

All in all, I think it's easiest to just apply the script.

If you're looking for things to do, more important would be to get the diode level 3 to work, as SkyWater uses these and I don't know how to make them compatible with the existing diode models.

dwarning commented 3 years ago

Tim, I got the hint from Holger to take care about the level 3 diode problem. So I want ask you if the request is right to have the hspice level 3 diode model. As I see it is only an capacitance extension for metal and poly parasitic capacitances. Can you approve please and compare the hspice equations to the spectre model equations. So it will be possible to implement these extension into next ngspice release.

RTimothyEdwards commented 3 years ago

@dwarning : The main thing seems to be that the level 3 diode takes an actual physical area and perimeter, rather than the "area scale" and "perimeter scale" (unitless) values of the standard SPICE diode model. Beyond that, there are a number of parameters that are not recognized when ngspice reads the device model. I don't know specifically what the model level 3 does, but I can show you which parameters ngspice complains about when it reads the model.

dwarning commented 3 years ago

Tim, thank you. I made an new ngspice development branch _diode_level3. Because I don't like the double parametrization on element and model level I introduced the 8 parameter at first as model parameter. I saw it is in line with skywater PDK requirements. I am sure that Holger will take it over in next release after further testing. Edit: Did you use both scale factors SCALE for element scaling and SCALM for model parameter scaling in your PDK?