@Tim Edwards when comparing pnp models with netgen, I’m getting a missing parameter error. Here’s the reduced layout:

X0 GND GND eg sky130_fd_pr__pnp_05v5_W0p68L0p68 M=8                               
X1 GND GND eu sky130_fd_pr__pnp_05v5_W0p68L0p68

and here’s the schematic

XQ2 vss vss net2 sky130_fd_pr__pnp_05v5_W0p68L0p68 NE=1 m=8
XQ1 vss vss vn sky130_fd_pr__pnp_05v5_W0p68L0p68 NE=1 m=1

and here’s the error message

Netlists match uniquely with property errors.
Circuit 2 bandgap instance sky130_fd_pr__pnp_05v5_W0p68L0p68:Q1 property "m" has no match in circuit 1.

With mosfets,

m

also only appears in the extracted netlist when there are more that two in parallel, but there are no warnings for missing parameters. Could the problem be that since the pnp model does not have any extracted parameters,

m

is not created as

1

when comparing? I tried adding

m=1

to the tech file device definition, but that doesn’t appear to work.

That seems more like some obscure bug that I will need to track down.

M

should always be implied for a subcircuit.

I did ignore the

NE

parameter because it is not extracted. Sorry for not mentioning that. I’ll create an issue.

@Tim Edwards the NE=1 is generated in the netlist for PNPs if a LVS netlist is specified. It is not written in netlists for spice simulations. The pnp symbol has an explicit

lvs_format="...."

defining the netlist rule for LVS, it was done on purpose, whereas

format="..."

is used for simulation:

lvs_format="@spiceprefix@name @pinlist sky130_fd_pr__@model NE=1 m=@m"
format="@spiceprefix@name @pinlist sky130_fd_pr__@model m=@m"

If the NE=1 string is inappropriate for LVS I can easily remove it.

@Stefan Schippers: But why would you change NE, which is a Gummel-Poon parameter for the B–E leakage emission coefficient (according to https://en.wikipedia.org/wiki/Gummel%E2%80%93Poon_model)?

@Tim Edwards the addition of NE=1 in pnp transistor netlist (for LVS purposes only) was done on Nov 24 2022. It was asked certainly by someone. I agree with you this is an internal model parameter and should not be changed, so it should not be an instance parameter. If you agree I can remove this (to me meaningless for LVS) parameter.

Yes, I agree that it should be removed; not a particularly high priority.