On the xschem_sky130 nfet and pfet symbols, it might be nice if the gate and backgate pins were not at the same y-coordinate, so that in a current mirror with many outputs, the gates of many fets could all be connected together by a single horizontal wire and likewise the backgates could all be connected together with another horizontal wire. (If there are models for nmos inside p-well inside n-well in the substrate, with the wells all brought to pins on the symbol, then ideally each of these pins would be drawn at different y-coordinates.) As changing the symbols would break people's schematics, I'm not sure how it would be best to manage the change - provide them as alternative symbols only for new designs perhaps. Also I think res_generic_po symbol shouldn't have diodes shown on it, if it is a poly resistor.

@Chris Jones yes i really do agree. whenever you think it is right time to do it let me know, just consider that that moving pins of symbol primitives requires editing schematics using them....

I would not like to break anybody's schematics right before tape-out, but maybe once the shuttle gds has finally gone to the foundry, might be the best time. I am not the right person to decide this.

@Chris Jones an interesting possibility is creating the '3 pin' versions of these transistors and set the body terminal via attribute. Since there are lot of designs where pwell and nwell are just VSS, VDD there is no real need for having explicit pin for it. Whenever needed (analog / insulated i-pwell designs) the 4 terminal is always available. The picture shows the body terminal set via attribute and resulting netlist for M9 (XM9)

Yes, the 3-pin versions would be great to have as well. I wonder whether the versions of the symbols have to be all separate, as it seems to me that it might be more ongoing work to maintain than a single symbol for each device type that somehow has an optional pin.

@Chris Jones ngspice is all the time bailing out with thos e equations, followin transistor description is not accepted. I have tried everything like using ' instead of {, }, removing the int() operator, renaming / removing the nf parameter. no success. Any hints? I have tried various older ngspice revisions as well as the newest ones.

XM8 D G S B sky130_fd_pr__nfet_01v8_lvt W=1 L=0.15 nf=1 
+ ad={int((nf+1)/2) * W / nf * 0.29} 
+ pd={2*int((nf+1)/2) * (W / nf + 0.29)}
+ as={int((nf+2)/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

This is the error:

Original line no.: 20, new internal line no.: 14623:
 Formula() error.
      l=0.15;w=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;nf=1;m=1;
Original line no.: 0, new internal line no.: 15120:
Undefined number [ad]
Original line no.: 0, new internal line no.: 15120:
Cannot compute substitute
...

Any suggestions? may be you see something wrong immediately....

No, I'm very inexperienced in this stuff, especially recently. I wonder if it is somehow parsing it incorrectly as one big formula but that is a wild guess.

@Stefan Schippers Did you manage to solve your problem with the FET area/perimeter equations in the instance parameter list? I'm having the same problem when trying to simulate my test circuit. The only way I can get it to work atm is by removing them from the netlist before running the sim.

@Tom, yes i can simulate with area / perimeter equations, but since AS,AD, PS, PD, depend on W and nf (number of fingers) i had to patch the sky130 pdk moving the declaration of nf parameter before the parameters that depend on it. Ngspice resolves the equations, but if nf comes after AD,AS,PD,PS, it reports nf as undefined. Unfortunately in the original pdk the nf param is at the end. If you want i can send you a patch file. You need to fix all *.pm3.spice files. original:

.subckt  sky130_fd_pr__nfet_01v8_lvt d g s b
+
.param  l = 1 w = 1 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0 mult = 1 nf = 1.0
msky130_fd_pr__nfet_01v8_lvt d g s b sky130_fd_pr__nfet_01v8_lvt__model l = {l} w = {w} ad = {ad} as = {as} pd = {pd} ps = {ps} nrd = {nrd} nrs = {nrs} sa = {sa} sb = {sb} sd = {sd} nf = {nf}

Patched:

.subckt  sky130_fd_pr__nfet_01v8_lvt d g s b
+
.param  l = 1 w = 1 nf = 1.0 ad = 0 as = 0 pd = 0 ps = 0 nrd = 0 nrs = 0 sa = 0 sb = 0 sd = 0 mult = 1
msky130_fd_pr__nfet_01v8_lvt d g s b sky130_fd_pr__nfet_01v8_lvt__model l = {l} w = {w} nf = {nf} ad = {ad} as = {as} pd = {pd} ps = {ps} nrd = {nrd} nrs = {nrs} sa = {sa} sb = {sb} sd = {sd}

@Stefan Schippers interesting! Thank you so much for figuring that out. Yes please that would be great!

@Tom, will send you the patch file asap. Will sync up my pdk with latest changes if there re any. Consider that it is not clear if this is a pdk fault or a ngspice fault. Ngspice devs admitted that parameter definitions should not be dependent on the order, but i do not expect ngspice to be fixed very soon it make sense to move the nf parameter in the pdk. I do not see drawbacks anyway.

@Stefan Schippers I agree. Thanks, looking forward to it.

@Tom here the patch file. It moves the 'nf' parameter before AD,AS,PD,PS and also fixes a couple of high voltage transistors that had the 'nf' parameter written as 'mf' (i don't know of any 'mf' instance parameter for MOS, so i assume this is a typo).

@Stefan Schippers Thanks very much for this. I'm applying it now.

@Tom Thank you for confirming, may be we can propose this parameter reordering to the pdk devs, i don't see any potential side effects, unless someone writes reverse equations for 'nf' that depend on AD, AS, PD, PS. May be @Tim Edwards can comment on this.

@Stefan Schippers: This all sounds good; the parameter reordering should be sufficient. Hopefully @Tim 'mithro' Ansell will have the sub-module repositories set up soon so that we can just make a pull request on the sky130_fd_pr repository directly.

@Chris Jones I have fixed the res_generic_po, being a poly resistor it does not have any diodes and bulk connection. I have enabled the symbol since i also found the model. I had to make some adjustments in the model file, since the model is not understood by ngspice:

.subckt  sky130_fd_pr__res_generic_po r0 r1
+
.param  w = 1 l = 0 mult = 1 r = 0 tc1 = {tc1rsgpu*sky130_fd_pr__res_generic_po__tc1_slope} tc2 = {tc2rsgpu*sky130_fd_pr__res_generic_po__tc2_slope}
+ rp1_mm = {rp1*sky130_fd_pr__res_generic_po__slope/sqrt(2.0*l*w*mult+rp1/100000.0)}
+ r_tot = {(rp1+rp1_mm)*l/(w-1e6*(-tol_poly-poly_dw))+r}
sky130_fd_pr__res_generic_po r0 r1 sky130_fd_pr__res_generic_po__monte r = {r_tot} tc1r = {tc1} tc2r = {tc2}
.model sky130_fd_pr__res_generic_po__monte r tref = 30.0
.ends sky130_fd_pr__res_generic_po

the resistor line starts with sky130_fd_pr__res_generic_po, i changed to rsky130_fd_pr__res_generic_po (resistor names must start with 'r') and also changed the tc1r and tc2r to tc1 and tc2 respectively. I am not 100% sure this is correct, however this way ngspice handles the resistor. the R vs temp for a 1/1 resistor is shown here. @Tim Edwards do you think it makes sense? I have bundled this change in the patch file that does the 'nf' param reordering.

@Stefan Schippers: That is probably sufficient, although note that there is an underlying problem that the original SkyWater file

sky130_fd_pr__model__r+c.model.spice

in the

sky130_fd_pr

library has the model

sky130_fd_pr__res_generic_po

. . . but it is commented out. I don't know why it was commented out, or if the model is correct, or if the model is the same as

sky130_fd_pr__res_generic_po__monte

. When I am able to make a pull request to the repository, this is one of the fixes I want to make (assuming the model is good).

@Tim Edwards Thank you, yes the model is not terribly complicated and the r vs temp (increasing) makes sense for low resistivity. Is this some sort of poly + salicide resistor? or just (high doped) poly?

@Stefan Schippers: It's an N+ poly resistor (poly + NSDM implant). It is not at all clear to me what the state of the salicide is; there is no such mask layer as "salicide block" as I normally expect to find in such processes. If it were salicided, I would expect more like 5 to 10 ohms per square, not 50. But then it seems rather low for unsalicided poly.