open_pdks
open_pdks copied to clipboard
RTimothyEdwards
sky130_fd_pr fixes for Xyce
I got Xyce working with the sky130 libraries and had to make these changes to sky130_fd_pr:
Change end of line comment form $ to ;
perl -p -i -e "s/\\$/;/" */*.spice
perl -p -i -e "s/\\$/;/" */*/*.spice
perl -p -i -e "s/\\$/;/" */*/*/*.spice
Comment out extraneous dev/gauss params
perl -p -i -e "s/dev\/gauss/; dev\/gauss/" */*.spice
Xyce-only change in how scale works (incompatible with ngspice)
perl -p -i -e "s/option/options parser/" models/all.spice
Extraneous malformed include statement is removed
perl -p -i -e "s/include.*//" cells/nfet_05v0_nvt/sky130_fd_pr__nfet_05v0_nvt.pm3.spice
Match .endl to .lib
The last fix involved changing the .endl cards to .endl
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
ugh. . . perl. . . : )
I'll figure out how to get this into open_pdks and provide an "official" level of xyce support.
Isn't it practically the same in "sed" though? Oh, yeah. . . ugh. . . sed. . . : )
This is why I do everything in python these days.
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
@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.
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
@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.
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
@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 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.
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.
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.
@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.
@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.
That is correct. I just confirmed that the regular nfet/pfet (and probably other devices) didn't used the special "diode" parameters.
@RTimothyEdwards is this still pending?
If not, where does a working model-file land after installation?
Thanks.
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.