@User What is the equivalent of dev/gauss in Xyce? https://github.com/google/skywater-pdk-libs-sky130_fd_pr/blob/f62031a1be9aefe902d6[…]7627436/cells/cap_var_lvt/sky130_fd_pr__cap_var_lvt.model.spice

Illegal parameter name: DEV/GAUSS

I don’t think that slash is supported for parameter names.

Evidently it is a spectre thing. We can remove it.

One problem with using the forward slash is that it is easy to conflate it with the division operator. To fully support forward slash in param names, the expression library would need to be smart enough to disambiguate it. Currently it isn’t smart enough to do that.

@Eric Keiter: It is actually a PSPICE thing, which makes me wonder why the SkyWater models have such a mix of this syntax and also Spectre syntax. I decided that apart from the space between the parameter and "dev/gauss", it is equivalent to (in ngspice) multiplying by function

agauss(0, 1.0, 1)

. So my question would be: Does Xyce have some equivalent to function

agauss(a, b, c)

(returns a gaussian-distributed random value mean=a, stddev=b, sigma=c)? Or should I be trying to work out a completely different method to handle monte carlo process and mismatch simulations?

@Tim Edwards yes, Xyce does support agauss and other random operators, using essentially the same syntax as Hspice.

Great, thanks. That should make it relatively easy to have installed files for sky130 that are compatible with both Xyce and ngspice. The main difference now is the ".option scale" in ngspice vs. ".options parser scale". The former is compatible across most versions of SPICE. Xyce seems to be the exception here.

Sorry about that. (

options parser scale

). That's kind of a historical pattern we've used in Xyce, that pre-dates our attempts to be compatible with other simulators. Years ago I had felt that I needed more flexibility for specifying different types of solver options. So, for example

.options timeint reltol=#

would apply to the time integrator and

.options nonlin reltol=#

would apply to the nonlinear solver. Our XDM tool (which converts files from Pspice/Hspice/Spectre to Xyce) would catch

.options parser scale=#

and change it to

.option scale=#

. But we don't currently have an explicitly ngspice grammar supported in XDM.

As far as I know, it's the only think, and if Xyce could treat

.option scale

as just a shorthand for

.options parser scale

, that would make things trivially simple on my side.

OK, glad to hear that it is probably the only remaining thing at this point. I will add that to our issue tracker.

I honestly hate the scalefactor, but it's buried in the model files and a lot of the device models depend on it, and pulling it out appeared to be a huge and error-prone task.

I'll also mention that "option scale" is currently only partially supported in Xyce, which is one reason we haven't really documented it yet. It currently doesn't work for models generated by ADMS, and only works in the hand-written models. However, for Sky130, that is fine. Sky130 uses BSIM4 models which we implemented by hand. So it supports scale.