Soft connection checking uses a modified tech file that must be updated when the base file changes.

[d-m-bailey]

@RTimothyEdwards We've talked about implementing the no-well extraction technology as a variant in the magic tech file.

Here are the base version and the no well version of the tech files I'm using for sky130A.

Is this enough information to create a variant? (maybe nowell)

tech.tgz

[RTimothyEdwards]

@d-m-bailey : I don't understand how it works to remove the substrate connection from the FET "device" lines in the technology file. If the extraction works the way I think it works, then the FETs will all be missing a terminal in the output netlist, which isn't a legal device since the models expect four terminals.

[RTimothyEdwards]

The device terminals are a general problem in that they are always "soft" connections---there is always some distance between the point under the device and the nearest well/substrate tap. This is generally enforced by DRC rules, although the DRC rules tend to be rather computationally expensive. I think there should be a way for the connectivity function to create for itself a different connectivity table which excludes the well and substrate types, and be able to apply that table selectively. That could be set based on a criterion for type resistivity, to exclude the high-resistance well and substrate types automatically. I have to look at the definition of the resistance calculation (the one in "extract", not "extresist") to see if it is sufficient to make a "soft" threshold based on wire resistance, which could be used to find soft connections through long poly or local interconnect wires.

[RTimothyEdwards]

@d-m-bailey : This would be a sort of coarse-grained check, but I'd like to know for layouts that have soft connection errors and those that use poly or local interconnect as long resistive routes, whether they show up clearly in the .ext file in the node statements for the net in question. The node line syntax starts out node <name> <R> <C> ... where <R> is a resistance calculated from the area and perimeter of each layer in the net. It should catch soft errors, but I just don't know how reliably. The calculation of <R> assumes a simple point-to-point wire, and anything with branches or loops or other complex geometry is going to have an inaccurate result.

[d-m-bailey]

@RTimothyEdwards By soft connection error, I mean a metal -> substrate -> metal connection. Or looking at connectivity from a top down view, 2 or more metal nets that are only connected by well/substrate.

If the extraction works the way I think it works, then the FETs will all be missing a terminal in the output netlist, which isn't a legal device since the models expect four terminals.

Exactly, I compare the netlists with 3 terminal fets. With the normally extracted netlist, the 4th terminal is removed programatically from before comparing. (I'm not sure what models your referring to. The netlists extracted for soft connection checking are not intended to be used for spice simulation. netgen doesn't care about the number of terminals on X devices, correct?)

[RTimothyEdwards]

@d-m-bailey : On principle, I don't like to generate netlists that are not simulatable. But I just didn't know that you were making a change to the other netlist to remove the substrate nodes.

[d-m-bailey]

@RTimothyEdwards I think I have a solution using variants. I'll post it soon.

[d-m-bailey]

Should be fixed by #382