flag_missing_ports false negative

[Scafir]

Hi Matthias,

When implementing flag_missing_ports on gf180, I stumbled on a situation in which I got an LVS clean, but it should have failed.

I have a bad schematic file:

.SUBCKT ppolyf_u_nwell MINUS PLUS SUB

R1 MINUS $1 W ppolyf_u L=35.7U W=0.8U
R2 $1 $2 W ppolyf_u L=35.7U W=0.8U
R3 $2 $3 W ppolyf_u L=35.7U W=0.8U
R4 $3 $4 W ppolyf_u L=35.7U W=0.8U
R5 $4 $5 W ppolyf_u L=35.7U W=0.8U
R6 $5 $6 W ppolyf_u L=35.7U W=0.8U
R7 $6 $7 W ppolyf_u L=35.7U W=0.8U
R8 $7 PLUS W ppolyf_u L=23U W=0.8U

.ENDS

Notice that the SUB and W are separate nets. In layout however, they are the same net.
When I run the LVS with flag_missing_ports I get an incorrect LVS pass, even if it is quite clear from the window that something is wrong:

How to reproduce

Download this file: flag_missing_ports_klayout.zip

unzip flag_missing_ports_klayout.zip
cd flag_missing_ports
klayout -b -r gf180mcu.lvs -rd input=ppolyf_u_nwell.gds.gz -rd schematic=ppolyf_u_nwell.cdl -rd report=ppolyf_u_nwell.lvsdb -rd check_ports=true -rd top_lvl_pins=true

I initially thought that this was because I was making simplifications on the schematic netlist, but even when manually deleting these from the gf180mcu.lvs script, the behavior is still the same.

[klayoutmatthias]

Hi Clyde,

thanks for the testcase. I'll take a look. Maybe it's because SUB and W is not strictly a "port" (i.e. does not carry a label). I agree it should be flagged, but after all, it will become detected somewhat further up in the hierarchy, when you miss to make a connection to some pad.

I'll check what's happening.

Matthias

[Scafir]

Hi,

From my limited understanding, W in the layout is an actual port: it has metal1 connected to it with a dedicated label. As such, I believe it is not just the global substrate net messing around, but an issue that could also happen on the toplevel.

Thanks for looking into this!

[d-m-bailey]

@Scafir I may be wrong, but this is what I see.

I think flag_missing_ports flags works like this.

For each port in the schematic, if the corresponding port in the layout does not match, then throw an error.

It does not flag layout text that does not correspond to a port in the schematic. i.e. Extra text in the layout does not cause an error.

The source netlist is

.SUBCKT ppolyf_u_nwell MINUS PLUS SUB

R1 MINUS $1 W ppolyf_u L=35.7U W=0.8U
R2 $1 $2 W ppolyf_u L=35.7U W=0.8U
R3 $2 $3 W ppolyf_u L=35.7U W=0.8U
R4 $3 $4 W ppolyf_u L=35.7U W=0.8U
R5 $4 $5 W ppolyf_u L=35.7U W=0.8U
R6 $5 $6 W ppolyf_u L=35.7U W=0.8U
R7 $6 $7 W ppolyf_u L=35.7U W=0.8U
R8 $7 PLUS W ppolyf_u L=23U W=0.8U

.ENDS

(Actually, this looks like an extracted netlist, but that's besides the point.)

It contains an unconnect SUB port. I think klayout ignores (as it should?) floating ports.

The W in the layout, is matched to the internal net W in the schematic. In the layout, it is considered a pin, but since there is no matching pin in the schematic, there is no error. Try expanding the net list results - you should see W matching between the layout and schematic.

So klayout is working as described as documented, I think. @klayoutmatthias correct me if I'm wrong.

[klayoutmatthias]

Hi @d-m-bailey and @Scafir,

originally, the function was designed to detect incorrectly connected pins - i.e. connecting net B to pin A. So it does not report pins that are present in the schematic, but don't have an equivalent in the layout. But in the sense of the name ("missing"), it's easy to make it flag pins that don't have a layout equivalent.

However, I wonder if that creates trouble with empty pins in the schematic. So maybe the error should only happen for schematic pins that connect to "something" inside the circuit (i.e. at least a device or a subcircuit)?

Matthias

[d-m-bailey]

I thought it flagged schematic pins that don't have a corresponding layout.

@Scafir can you "fix" the source cdl by changing the W to SUB so that SUB is not floating and see if the layout W - sourceSUB mismatch is flagged?

[klayoutmatthias]

Hmm ... I see the situation here is a bit difficult.

Basically, the schematic is regarded "the truth". So if I take the CDL seriously, "W" is an internal net and "SUB" is an idle pin.

As there is no specific pin marker currently, all labelled nets are made pins for the top level circuit ("make_top_level_pins"). In that case, "W" becomes a pin, but that simple scheme tends to create too many pins. So layout "pins" are treated "optional" pins that do not need to match with schematic pins. That may change, if real pin objects are introduced. But right now, that is the way it is. That explains, why there there is no error for the mismatching "W" pin. The "W" nets are matching, and that is enough.

Regarding "SUB", I could raise an error. However: I see idle pins sometimes in schematics. Idle pins cannot have a layout equivalent except maybe a floating net. But floating nets happen very often for other reasons (dummy fill, labels etc.), so they are eliminated from the extraction. So I wonder if it's a good idea to raise an error when an idle pin does not have a layout equivalent. Maybe a warning makes sense or would that flood the log with too much noise?

Matthias

[Scafir]

@Scafir can you "fix" the source cdl by changing the W to SUB so that SUB is not floating and see if the layout W - sourceSUB mismatch is flagged?

In this case, the issue is correctly flagged.

I think I agree with your approach @klayoutmatthias . Until we have an official way to nominate pins, it makes sense to treat the layout named nets as "optional" pins, which get nominated to actual pins if they have a netlist equivalent. I fear that a warning per idle pin would flood the output too easily (maybe a single warning like There are more named nets in layout toplevel than in the schematic, ignoring non-matching nets?)
I could try to make a PR to improve the documentation on flag_missing_pins if you'd like, which I think would have avoided me raising the issue.