I would like use SKYWATER 130nm library in Hspice simulator . Is that possiple?

I am not spice simulator expert. @Mitch Bailey can you share your thought? thanks

Very little spice experience here, also. Sorry.

@İbo İbo: Hspice is considerably more compatible with ngspice than Spectre is, so you might get by with just using the model files the same way as ngspice does. We obtained the models from SkyWater only in Spectre format, and converted them to something ngspice-compatible, so as far as I know they have not been specifically tested in Hspice, Pspice, or any of the other commercial SPICE variants.

I tried a while ago, but couldn't get Hspice to read the models without doing some syntax hacks. I ultimately gave up since doing this for all files is tedious, unless one spends time on automation.

@Boris Murmann: Thanks for the clarification. I have a pretty good handle now on how to convert from Spectre syntax to ngspice syntax; I guess some time I'm going to have to learn all the gotchas for converting to and from Hspice.

I tried using bsim4 models available in .spice files a while ago. I encountered an error which was using "{" instead of "(" which was not defined in Hspice. I used notepad++ to replace all of them. But as you mentioned it exists for all transistor models in the file. Eventually i made it working for tm model. But looking at gm/id versus inversion coefficient, there was a kink in moderate inversion which I haven't seen in other technology model files.

Yes, that sounds exactly like my experience. The kink is also there with ngspice, though; a sign of bad models. Will hopefully be resolved once the new models are released.

For which we need to keep pressuring @proppy who has the continuous models. @proppy: Is there any concern with just posting the continuous models "as is"? It is far more important that the models should exist in the repository than that they be organized or even correct. Organization and errors can be corrected.

@Tim Edwards I'm currently in sick leave, happy to take a look at https://github.com/google/skywater-pdk/issues/380 again when I'm back to work. One thing I wanted to do was to verify that the new model fixed the anomaly @Boris Murmann reported on the linked issue: https://github.com/google/skywater-pdk/issues/381. I also wanted to understand the heavy renaming/file move that you mentioned having to do in order to integrate it properly with the PDK.

The main thing for integration into the PDK is that

sky130.lib.spice

needs to be changed to include the new continuous models instead of the old discrete ones. The main issue is that there are many devices which are not included in the continuous models, mainly because they are devices with fixed layouts, and so there is only one characterization bin for the device and therefore nothing to make continuous. But there are included files of parameters that contain parameters for both the devices that are being replaced by the continuous models, and also the devices that aren't being replaced. Those files need to be hacked up a bit to cleanly separate the parameters that are still being used and the parameters that are no longer needed. However, for most purposes not involving RF devices or some of the more unusual devices, it's pretty easy to just include the continuous models. So there really is a huge benefit to just dropping all of it into a PR branch. Once you do that, I can fork the repo and send you more pull requests dealing with the reorganization, which I've already done here locally but can't make public.