How to make all model parameters numbers, not equations

[Matt Clapp]

I'm using xschem with open_pdks sky130 pdk.

I'm troubleshooting creating a netlist with xschem and submitting it to my simulator. I have an in-house simulator that doesn't like the fact that some parameters in the MOS devices are equations based on other parameters.

For example, trying to simulate with a pmos in the netlist like this:

XM1 net1 net3 VDD VDD sky130_fd_pr__pfet_01v8_lvt L=0.35 W=1 nf=1 ad='int((nf+1)/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29'
+ pd='2*int((nf+1)/2) * (W/nf + 0.29)' ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd='0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1

yields this error:

ERROR: XM1: cannot evaluate parameter 'AD' with 'int((nf+1)/2) * W/nf * 0.29' value (unknown parameter or signal 'nf' in formula 'int((nf+1)/2) * W/nf * 0.29')

My simulator is not connecting the parameter 'nf' which is defined only for this instance with the equations in other parameters for this instance.

Is there a way to either 1.) make all parameters evaluate to a number before outputting the netlist, or 2.) otherwise provide syntax or a directive to help my spice simulator understand that the parameters in the equations should come from the same instance?

thanks,
Matt

[stefan]

Hello, Matt. I guess your simulator has problems also with W instance parameter in the calculation of ad,as,pd,ps etc parameters? or is it only having issues with nf?

[Matt Clapp]

Hi Stefan, thanks for replying.

Yes I just tried an experiment where in the netlist I replaced every nf with 1. As expected it then complained about W:

ERROR: XM1: cannot evaluate parameter 'AD' with 'int((1+1)/2) * W/1 * 0.29' value (unknown parameter or signal 'W' in formula 'int((1+1)/2) * W/1 * 0.29')

So in the original case I think nf was merely the first variable it couldn't locate. It's ok with the equations, but it doesn't seem to think the equation parameters can come from the instance parameters.

I'm also following up with my internal tool support for the simulator to see if somehow the simulator can bridge the gap.

Do you know if this is how some known variant of spice handles things: disallowing parameter equations based on other parameters? Or is there some special syntax that says "this variable is from this instance"?

Otherwise, can something be done with xschem, or is it a matter of changing the models?

thanks!

[stefan]

The equations provided for ad, as, pd, ps are reasonable guesses of the areas and perimeters of the transistor as it is drawn on the layout. It is very boring to define W, L, nf, Ad, As, Pd, Ps, Nrs, Nrd, Sa, Sb, Sd for any transistor you place in a schematic, yet these parameters are important for a first order parasitic capacitance estimation of the transistor. It is possible for xschem to generate numbers instead of formulas, but this is possible only if W, L, nf (the primary geometric parameters) are given as numbers.
Often designers create spice parameters (.param WN=10 LN=0.15) and use these parameters in the transistor instantiation (W='WN' L='LN')
in this case xschem can no more generate 'numbers' for the remaining model parameters.

When placing a transistor in the sky130 pdk you can however override the equations by adding all these parameters as numbers in the instance. See image,with transistor attributes on the left and resulting netlist line on the right.

[stefan]

It is probably possible to create a "helper function" that creates these attributes (ad, as, pd, ps, ....) for all transistors automatically given W, L, nf and mult.
However this is dangerous if you later resize the transistor as you will need to recalculate these parameters (may be by triggering again the helper function).

[stefan]

For the parameter definition I have verified that both Ngspice and Xyce (both are used with sky130) use parameters defined on the instance line and if not found then look for global parameters defined with .param. when equations depending on parameters are found.

I have done a simple test with a cmos diffamp and the frequency response is destroyed by putting an insane drain junction area, like ad="'W * 10000'" in one of the output transistors

[Matt Clapp]

Thanks for all the investigation and explanation. I've had the benefit in the past of having other people set up my CAD tools, so I must admit some ignorance with all the different variants of SPICE and what is possible/impossible. :)

For a while I was just wondering why the models don't just use these equations to find ad,as,..etc, but I realize now that you want to be able to set these if you want, and otherwise settle on reasonable defaults (these equations).

For the helper functions, is there any command in xschem for a schematic to say "re-run all helper functions now" ?

Otherwise if my simulator tool support has no answer, I think it might be time for me to make a python script to translate all the parameter equations into numbers.

thanks again

[stefan]

I have pushed a change to the definition of ALL mosfets in xschem_sky130 and a commit (here for sourceforge) in the xschem program too.
Now all expressions for ad, as, pd, ps, nrs, nrd are reduced to expressions with only numbers, with nf and W replaced with the assignments done in the instance. This removes one lookup level for the simulator.

A transistor netlist line looks now like this:

XM1 net1 net2 net3 net4 sky130_fd_pr__nfet_01v8 L=0.5 W=2 nf=1 ad='int((1 + 1)/2) * 2 / 1 * 0.29' as='int((1 + 2)/2) * 2 / 1 * 0.29'
+ pd='2*int((1 + 1)/2) * (2 / 1 + 0.29)' ps='2*int((1 + 2)/2) * (2 / 1 + 0.29)' nrd='0.29 / 2 ' nrs='0.29 / 2 ' sa=0 sb=0 sd=0 mult=1
+ m=1

If should be possible for xschem to evaluate these expressions and present in the netlist only the result. However this works only if W, nf are given as numbers. If a transistor is placed with W=WN (where WN is a spice .param) this is no more possible. In this case expressions should be left unevaluated:

XM1 net1 net2 net3 net4 sky130_fd_pr__nfet_01v8 L=0.5 W=WN nf=1 ad='int((1 + 1)/2) * WN / 1 * 0.29' as='int((1 + 2)/2) * WN / 1 * 0.29'
+ pd='2*int((1 + 1)/2) * (WN / 1 + 0.29)' ps='2*int((1 + 2)/2) * (WN / 1 + 0.29)' nrd='0.29 / WN ' nrs='0.29 / WN ' sa=0 sb=0 sd=0 mult=1
+ m=1

To enable expression evaluations in xschem I need to code or include an expression parser, I don't want to do this task with scripts (TCL or whatever else) since this is dead slow.
The expression parser should be smart enough to report if epression can be evaluated and if not the unevaluated expression should be used in the netlist.

[Matt Clapp]

Hi Stefan,
Wow this is amazing! Thanks so much for this addition to the code!
If it's buildable right now I'll try it out.
thanks!
Matt

[Matt Clapp]

I just tried to compile and run the version of xschem with your commit. I can see your new code inside of src/token.c

Do I need to change any options or modes for this to work?

Unfortunately I don't see any difference in my netlist. The instances still look like this:

XM1 net1 net3 VDD VDD sky130_fd_pr__pfet_01v8_lvt L=0.35 W=1 nf=1 ad='int((nf+1)
/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29'
+ pd='2*int((nf+1)/2) * (W/nf + 0.29)' ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd=
'0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1
XM3 net2 net1 GND GND sky130_fd_pr__nfet_01v8_lvt L=0.15 W=1 nf=1 ad='int((nf+1)
/2) * W/nf * 0.29' as='int((nf+2)/2) * W/nf * 0.29'
+ pd='2*int((nf+1)/2) * (W/nf + 0.29)' ps='2*int((nf+2)/2) * (W/nf + 0.29)' nrd=
'0.29 / W' nrs='0.29 / W' sa=0 sb=0 sd=0 mult=1 m=1

I've attached the debug level 1 output.

[stefan]

You need to replace also the transistor symbols with the newer ones that are here.
You can clone the repo and copy all the symbols in sky130_fd_pr/ dir into your pdk sky130 installation (somewhere in .../share/pdk/sky130A/libs.tech/xschem/sky130_fd_pr).
Delete all the ad, as, pd, ps, nrs, nrd, sa, sb, sd in the instances so xschem will pick the ones defined in the (new) symbols. See image.

[Matt Clapp]

Got it working. Thanks for all your help.

[Anonymous]

I belive that standard SPICE model instance arg figuring will fall back to calculating S/D area & periphery numbers using w, nf and some fixed model params (LD, LS?). This ought to be roughly right, maybe off for some nf (odd / even vs Cj partitioning / rollup wants some informed logic).

Might check on whether the models do this figuring with no passed a, p args ( just because it says "dpice" does not imply total compatibility with all ither "SPICEs". Or that the default region L value has been set, right.