@User: If you could, please: The

sky130_fd_pr

device

sky130_fd_pr__pnp_05v5_W3p40L3p40

has always had a problem that the layout pin names don't match the SPICE model pin names (the

W0p68L0p68

device is worse, because the layout doesn't have any pins at all. . .). Also, the PNP devices cannot have a 4th substrate terminal because the collector is already equal to the substrate. I have a patch file now in open_pdks that changes the SPICE netlist pin names to "Base", "Collector", and "Emitter", and removes the 4th terminal. Can you please change the PNP device model in xschem to match?

Hi, @Tim Edwards what am i supposed to do? the spice model looks like:

.subckt  sky130_fd_pr__pnp_05v5_W3p40L3p40 c b e s

so there are 4 pins in the order c-b-e-s (collector, base, emitter, substrate). What is the equivalent layout order/naming? Changing the symbol netlist rule is easy, but i don't know what to change without breaking spice netlist. Of course in no circumstance should the substrate and the collector be different. I can enforce that by removing altogether the substrate pin and setting it equal to the collector pin in the generated netlist.

(1) The layout has pin names "Base", "Emitter", and "Collector". (2) Order is the same, just drop the substrate (4th) pin. (3) The SPICE model, with the most recent open_pdks install (which is applying patches), looks like

.subckt sky130_fd_pr__pnp_05v5_W3p40L3p40 Collector Base Emitter

. It is easier to enforce that the collector and substrate must be the same by removing the substrate pin from the subcircuit call (the model is now called with

Collector Base Emitter Collector

).

@Tim Edwards i am doing the pin renaming on the pnp device. In the mean time i reinstalled the whole pdks tree (using instructions in opencircuitdesign, together with all prerequisites, like rebuilding magic, ngspice and downloading skywater-pdk). I have verified that the pnp model installed in pdks/ has only 3 pins (collector, base, emitter) and so does the modified pnp symbol.

@Stefan Schippers: Use

.lib

with

sky130.lib.spice

, not

.include

, and give it a corner name as an argument.

Oh sh**...... sorry for being so stupid..... Thanks

@Stefan Schippers: I do not know what happens if you specify more than one corner in the

.lib

statement. Maybe it ignores the second? My method has been to add

.param mc_mm_switch=0

at the top of the testbench. The

mc

corner has been added for supporting statistical process variation; it cannot (should not?) be combined with another corner. The problem with the mismatch analysis switch is that I cannot find a way to have the parameter defined as 0 by default and overrided it when needed. If I put a .param line in the sky130.lib.spice file, then it becomes a permanent setting and I cannot override it. But unlike the statistical process variation, the mismatch switch can be combined with any process corner. The only solution I can think of is an ugly one, to double the number of entries in sky130.lib.spice and have separate entries for "corner without mismatch" and "corner with mismatch". But I really don't like that solution.

Thanks @Tim Edwards i was prepared to add the .param as you described, but before that i did a blind trial with

.lib .... tt mc

, and apparently it loads both library definitions. (tt, typical process corner and mc, montecarlo defs). But i cannot find any proof of that behavior in the manuals so a better approach would be to have 2 .lib lines.

The problem is that

tt

and

mc

have the same parameters in them, so only one of them can actually be in effect whether or not both of them are read, and there is no indication of which one would take precedence.

@Tim Edwards Ok, understood. Thanks!

I'm making as few changes as possible, but the PNPs were a mess, because the 3.4um layout overwrote the 0.68um layout, and magic can't extract four terminals from a device that has only three. I'm now collecting all sorts of patches to the repository in open_pdks. When the PDK continuous integration scripts are ready, I can start making pull requests against the PDK repositories. We are moving forward with the CI scripts now, after a number of weeks of being stalled.