klayout
klayout copied to clipboard
Support for Soft Connections
Soft connections are generally used to detect missing connections to power or ground. From an LVS standpoint without soft connection checks, connecting two nodes through nwell is the same as connecting them with metal even though the resistance is much greater.
Soft connection checks are implemented as "one way" connections where a lower shape connected to 2 different nets would be an error. Commercial tools report errors on either the top layer, contact layer, or bottom layer.
Is this possible to implement in klayout?
Well, I think this is possible to add.
However, I think the scheme needs to be a little more elaborate than that. First, the bulk nodes of the PMOS devices also connect to nwell without harm. So there are connections are are an error and some which are not. Second, the situation is more complex for (p) substrate which is equally important than nwell, but does not have a shape and is a global net.
Matthias
@klayoutmatthias Thanks for the response.
First, the bulk nodes of the PMOS devices also connect to nwell without harm. So there are connections are are an error and some which are not.
But the bulk nodes of pmos don't pass connectivity to the nwell do they? They get connectivity from the nwell. Correct me if I'm wrong.
For psubstrate, I use the klayout extent function to generate a layer covering the entire area. This area can be virtually divided (with a gds recognition layer such as substrateCut [in sky130 81/53]) for designs that have several ground nets (such as vssd1, vssa1) that are only allowed to be connected through psubstrate.
Hi @d-m-bailey,
The bulk nodes are actually implemented as device-internal connectivity - the devices produce terminal shapes that are connected to the layers passed to them in the device extraction. So the bulk terminals are a kind of connection and somehow the scheme needs to consider that.
For the p substrate, using a big shapes for the connectivity basically works, but that might spoil hierarchical performance and leave a flat netlist. "connect_global" avoids this, but there is no option to partition the substrate area (yet).
Matthias
I reviewed my options and I think the best implementation goes along the line of treating soft connects as kind of "unidirectional breaks" (think of diode devices). In the hierarchical domain, the nwell potentially becomes a hierarchical net on it's own, so checking whether it is connected to multiple metal nets, is not possible locally.
The breaks will keep the subnets separated in the first pass. The idea is to identify invalid soft connects - those are nets where two or more of these break "diodes" lead to different nets in "forward" direction. This check can be done hierarchically from the innermost subcircuit and hopefully this approach yields reasonable error messages.
In a final step, the breaks are removed and the disconnected subnets are joined into one.
These are my own thoughts, not copies from some commercial tool manual.
@klayoutmatthias thanks for looking into this.
Besides the normal substrate, nwell, pwell soft connections, I've also used the soft connections capability for diffusion and poly to detect missed connections.
I don't know how difficult it would be to implement a generic (possibly multi-level) soft connection check. For example, soft connection from metal to diffusion tap and then again from diffusion tap to well.
I created a feature for this. The idea is to replace "connect" by "soft_connect(upper, lower)" and "connect_global" by "soft_connect_global" to specify a directional connection. The implementation allows different sorts of soft connects (multiple such statements).
If soft connected nets are not joined, a warning or (in top level mode) error is produced in the log view. The error is a hard stop.
The feature is ready for release from my side. It will go into version 0.29.
Matthias
@klayoutmatthias Excellent! Look forward to trying it out.
You might get claims about the hard stop for top level errors. Some designers might want to ignore errors in non critical regions (for example an irrelevant psub tap in an isolated region).
I only included nets that have some relevance - i.e. connect to devices. So I hope that makes the feature smart enough to tell such cases from real ones.
In the end you can always choose not to use top level mode and waive manually.
But anyway, this is just the beginning. Open Source is about releasing and collecting feedback :)
Matthias