Hi Tim,
Curious what the status of this is in open_pdks?

from open_pdks.

ugh. . . perl. . . : )

I'll figure out how to get this into open_pdks and provide an "official" level of xyce support.

from open_pdks.

This is the one perl command I cannot get away from. :)

from open_pdks.

Isn't it practically the same in "sed" though? Oh, yeah. . . ugh. . . sed. . . : )

This is why I do everything in python these days.

from open_pdks.

I forgot one more:

VT is reserved parameter in Xyce

perl -p -i -e "s/vt/local_vt/g" cells/res_iso_pw/sky130_fd_pr__res_iso_pw.model.spice

from open_pdks.

@mguthaus : I just pushed a commit (to opencircuitdesign.com) that implements everything above except for the "all.spice" file change. I am working on figuring out what to do with the agauss() function calls. Since I am trying to implement support for both ngspice and Xyce, then editing all.spice is not acceptable and I need a separate xyce/ target directory, and a number of files will need to be copied and edited. How much needs to get copied and edited depends on the solution to the agauss() calls, so I'm holding off on that until I can get Xyce working and study its syntax quirks.

from open_pdks.

I think that the fixes to sky130.lib.spice are off. The .endl tags don't match. Some have duplicates:
.endl tt tt
which should be:
.endl tt
and others have this:
.endl tt tt_mm
which should be:
.endl tt_mm

from open_pdks.

@mguthaus : I'm guessing that it's because you made changes directly to the skywater_pdk repository contents in support of Xyce. If the sky130.lib.spice already had, e.g., ".endl tt", then it would just append it again.

from open_pdks.

Doh. Yes. This also explains the modifications to all.spice.

from open_pdks.

Looks like there is another issue with model parameters in the special SRAM transistors. Specifically these need to be commented out:
*+ ldif = 0.0
*+ hdif = 0.0
*+ rd = 0.0
*+ rs = 0.0
*+ rsc = 0.0
*+ rdc = 0.0
*+ nqsmod = 0.0

in these files:

libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_pass.pm3.spice
libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_pfet_pass.pm3.spice
libs.ref/sky130_fd_pr/spice/sky130_fd_pr__special_nfet_latch.pm3.spice

from open_pdks.

@mguthaus : From your post in the slack channel, it sounded like these parameters really are not supposed to be in the BSIM model used for these transistors? If not, then what is ngspice doing with them? Anything? Is that why they're all set to zero?

from open_pdks.

From my discussion with Eric and reading further, these specify the src/drain diodes. When the ACM=0 (which it is), the ldif and hdif parameters shouldn't be allowed. ngspice seems to just ignore them.

The other parameters, rs rd rsc and rsd, all default to zero and so shouldn't matter anyways. These are extended hspice parameters that aren't a part of bsim3 and ngspice seems to take them.

The nqsmod seems to have switched between bsim3 versions. From the spec:

The parameter nqsmod is now an element (instance) parameter, no longer a model parameter in
the release of BSIM3v3.2.

The default was 0, so it can be excluded without effect.

from open_pdks.

Browsing thru the ngspice source code, it looks like they did add various ACM model parameters to the BSIM3. They seem to mostly be geometrical parameters that modify some of the existing BSIM3 model equations. They aren't part of the original Berkeley BSIM3. Since they are present in the ngspice source, and they are under the modified BSD license, it wouldn't be hard for me to implement them in Xyce if necessary.

The NQSMOD param turns on the so-called "Non-quasi-static" model, and it is something that was in the original BSIM3. I've never actually seen anyone use it. Interesting that they elevated it from model parameter to an instance parameter at some point. From what I understand it is designed for situations where the circuit switching time is comparable to the transit time in the channel, so they've made the equations less instantaneous. To the extent that I've tried to understand this model, it looks like it makes the BSIM3 more expensive to evaluate, so that might be one reason it isn't used much. I actually never implemented the NQS model in the Xyce BSIM3, but since nobody using Xyce has ever set NQSMOD to anything but zero, that hasn't been an issue. But, similar to the ACM model params, if it was really necessary I could put it in there.

In other news, I've finally managed to fix the issues with "scale" and agauss. Both of those features can now be used in a Xyce netlist without causing any problems. My fix only got into the code today, however, so it won't be in the public Xyce git repo until next week.

from open_pdks.

FYI we (Xyce) are working on the multiplier (M=) issue this week. Most devices support it, but a few (particularly the diode) did not until this week. We are also working on it for subcircuits.

from open_pdks.

@mguthaus : It's one of the items on my to-do list as I work through a host of backlogged items that were waiting for the last SkyWater shuttle runs to be done with and out the door.

from open_pdks.

@mguthaus : Don't hesitate to keep pinging me about it, though.

from open_pdks.

@mguthaus : The SRAM core device models were the only ones throwing an error in Xyce? I added a script to the open_pdks Makefile to correct those per your instructions above. Let me know if there is anything else required.

from open_pdks.

That is correct. I just confirmed that the regular nfet/pfet (and probably other devices) didn't used the special "diode" parameters.

from open_pdks.

@RTimothyEdwards is this still pending?
If not, where does a working model-file land after installation?
Thanks.

from open_pdks.

FYI we (Xyce) are working on the multiplier (M=) issue this week. Most devices support it, but a few (particularly the diode) did not until this week. We are also working on it for subcircuits.

I wanted to mention (for anyone following this thread) that the subcircuit multiplier was recently fixed in Xyce, among many other compatibility issues. We are converging on our Xyce 7.5 release, which will be completed very soon.

from open_pdks.