@User I got sidetracked into a separate issue on Monday so I’ve been focusing on that. The short answer is that it is easy to do a “quick fix”, and I’ll probably do that for now. There is a more comprehensive issue that this work has illuminated for me, that I’ll also (eventually) need to fix. I was trying to figure out if I had time to do the comprehensive fix, or the quick one. But I’ll probably just do the quick one for now and revisit this later.

Out of curiosity what is the "more comprehensive issue" you're referring to?

He was talking about the issue of dependent vs independent parameters. They need to solve when and how often to apply the scaling in that case.

Ah yes, that does muddy the waters. How does ngspice handle it?

No idea, sorry 🙂

There’s even more to the comprehensive issue than that, but the details might not be that interesting here. Basically, I want to make sure that the “setup” code in device models is called as little as possible, because those are actually pretty expensive functions. If you naively call them (say) at every time step, then the run time gets like 10x worse, for example. Fortunately, I’m not doing anything that bad. But basically, you only want to execute the setup code on a device if a parameter it depends on actually changes. I completely rewrote expression and parameter handling last year and I don’t have this perfectly optimized yet. So, this issue (with the scale factor) overlaps this larger issue.

Model setup can absolutely be a pain in the neck. I am interested in what the "dirty fix" for the scale issues is. Have you pushed it to any of the branches?

The dirty 2-line fix is simply to hack the BSIM4 setup function to only let it apply the scale factors one time. That will fix this use case, where agauss is being used, but no sampling is being performed. But it will still be broken if sampling is performed and applied to scaled L,W parameters. Unscaled L,W could be sampled just fine. And other parameters could be sampled just fine. The only broken thing would be sampling L,W when “scale” is applied. Then scale has to be correctly applied every time L or W is updated.

Understandable if you have to play with the Xyce sourcecode itself (breaking sampling for the sake of scaling is...icky). Has anyone had any success unraveling the include trees and manually removing/appropriately applying the the scale factors?

@Robert Rogers I don't think anyone is working on that.

ngspice's dialect seems relatively compatible with Xyce's barring the scaling issue. performance aside, it'd probably be useful to have a xyce-native branch of the current ngspice netlists. Getting the scaling factors right might end up being a chore though. Has anyone tried to your knowledge?

Ultimately, fixing this “the right way” isn’t that hard to do. It just takes a little more typing and testing than I had time for earlier in the week. But I’ll get on it.

Are you aware of any tweaks necessary to the netlist codebase in the main branch PDK to make it interpretable by xyce (minus the scaling bit)?

If you are talking about Xyce branches (that are public anyway) I think the master branch over on github is as good as it gets the moment.

I was more referring to the SPICE netlists in https://github.com/google/skywater-pdk-libs-sky130_fd_pr/ To my knowledge those are all in the ngspice dialect which (I believe) has a few syntactical differences vs. Xyce's dialect. I was curious whether anyone had done the translation necessary to get them to run with Xyce (barring the aforementioned scaling bug)

Ah. Then you might find this comment from @Matthew Guthaus useful, if you haven’t seen it already: https://skywater-pdk.slack.com/archives/C01TLV579C5/p1623177011093000

@Robert Rogers i've been working with tim edwards on this in open_pdks https://github.com/RTimothyEdwards/open_pdks/issues/124

The scaling issue that is?

yes

Gotcha. Looks likea few perl oneliners do most of the work. I'll run those on my local copies and then try and unravel the include trees/get the scaling factors down for...probably just an nfet and a pfet. that would be sufficient for my needs. I'll keep an eye out for when the scaling bug gets fixed. Thanks all. I'll review the above links. If you remember any niceties or finicky bits you had trouble with please lmk. Otherwise i'll report back with the results of my "by hand" scaling fix for a small subset of the pdk.

And this one gets rid of the scaling problem by removing agauss everywhere:

perl -p -i -e "s/\+MC_MM_SWITCH.*\}/\}/" */*/*/*.spice

That would be good for now...actually.

There is only one scale in the libraries

Sorry for my ignorance, but what is it about agauss that throws off the calcs?

agauss causes the scale factor to be applied twice

Yep, i got there eventually.

@Robert Rogers These were just the changes needed to get a basic transient simulation of transistors working.

@Matthew Guthaus the conflicts between agauss and scale have been fixed in my local branch of Xyce. The fix should appear in the next synchronization we do with the public git repo. Knock on wood, that should be Monday.

Thanks for the hard work/making the time!