@User, I have an LVS issue which I've boiled down to a small current mirror. I've been staring at it for a while now and I can't see why it's not matching up, however, when I short

d1

and

d2

in both layout and schematic it works but the connectivity for the un-shorted versions look correct to me. If you or anyone get a chance to put a second pair of eyes on it I'd be extremely grateful. I've attached the files in case you don't mind taking a look.

@Tom Can you attach the extracted netlist? It should be somewhere around

results/magic/bgr_amp_lvsn1.gds.spice

Hi @Mitch Bailey, here are the files. I've not had a chance to look at it for a few days now as I'm away, thank you for taking a look if you feel like doing so but I don't want you to waste your time otherwise as I've probably made some silly mistake.

@Tom: Your problem is that you have dummy devices in your layout that are not represented in the schematic. Either you need to add them to the schematic, or since they have all pins shorted together, you can use the "ignore shorted" (e.g.,

ignore shorted {-circuit2 sky130_fd_pr__nfet_g5v0d10v5}

) command in the netgen setup file.

But M1 is my dummy device @Tim Edwards, with all terminals connected to

VSS

. It's a 4 finger device representing the two fingers at each end. I did the same thing in a previous LDO design and it passed netgen LVS with no issues. Are you saying there's an issue with the way I've instantiated/connected M1 in the schematic?

Do you have

ignore shorted

in your setup file for netgen?

Let me check. I doubt it since I've not made any changes to the default and I have other designs with dummies passing but I'll confirm and get back to you

netgen does not ignore dummy devices unless you tell it to.

Ok so it should not be ignoring them then

And that's why the LVS report says you have one more device in the layout than in the schematic.

Sorry @Tim Edwards, I'm confused. I have 28 fingers in my layout and 28 fingers in my schematic. 4 fingers in my schematic 'M1' are shorted to VSS (all terminals), and 4 fingers in my layout are also shorted to VSS (all terminals), two at the left end, and two at the right end. I have not told me then to ignore shorted devices which is why I have the dummies in the schematic represented by M1 the remaining 24 fingers in the layout are represented by schematic devices M6, M13, and M25. Sorry if I'm missing your point. Does what I said make sense?

@Tom : My mistake. I just saw the LVS report said that the layout has one extra device, and since the layout has a dummy device, and that's a common problem, I made an assumption. I have looked at the schematic netlist but not the schematic itself because I ran into the same problem that other people have been reporting with xschem not finding directories when a schematic is ported from one filesystem to another. I'll look again and see if I can find something else.

Ah understood. Thank you for the help!

No, I've figured it out. This is a kind of fallout (the usual kind---unintended consequences!) of a change I made to try to keep the runtime down on large digital standard cell layouts. I ended up making devices that have the same unconnected terminal to be considered "parallel". The reasoning is that cells like the antenna diode cell in the standard cell set can occur thousands of times, with no connection to the diode, and it looks to netgen like a thousand symmetries in the netlist and gives netgen fits. I think the proper solution is for me to not parallelize any devices that way in the top level. There's a workaround to it, which is what I consider the recommended way to do it, which is (1) make the labels in the layout into ports, so that magic can generate a subcircuit record in the netlist output; (2) make the circuit under test a standalone schematic in xschem (without any testbench circuitry in the same schematic), then create a symbol for it, then create the testbench so that it has all the testbench components and the symbol for the circuit under test. Then netlist both of those (you can netlist just the device under test by passing a pair of names to netgen for each netlist, in quotes, the first name being the file and the 2nd name being the name of the subcircuit).

I have another odd case which I was going to dig into more and can share when I get the chance, where a PMOS diff pair schematic with 4 nets not 5 (because I shorted the outputs while debugging) is only being identified by Bergen as having 3 nets

Yes, it is combining nets d1 and d2 in a particular way that would be correct if it were doing the same thing on the layout side, which it isn't. It has something to do with the fact that the devices in the schematic are fingered but the devices in the layout are output individually. I did find a simple workaround, which is to issue the command "property parallel connected" in the netgen setup file.

What does that command do?

It prevents netgen from attempting to combine in parallel devices that it considers to have "similar no-connect pins".

Ok. Do you recommend I add this to my setup file or wait for a patch to netgen?

Netgen commit

47e7367c26e6de314e9040656c5fb502099f7422

on the master branch at opencircuitdesign.com

👍🏻👍🏻

The specific way the layout and schematic netlists are done is uniquely problematic for netgen. The commit basically applies the

property parallel connected

command automatically when two top-level netlists are passed to it, which seems to be the primary way that netgen gets confused, that combined with the use of fingers in one netlist vs. individual devices in the other. I have thought about getting the extractor in magic to identify fingered devices but I have have not tried to sit down and figure out how to code it.

do you recommend using

mult

in the schematic rather than

nf

to make things clearer? I only use

nf

to get more accurate area/perimeter calculations but I actually prefer the schematic annotation you get when using

mult

anyway.

No, use

nf

because it is correct for simulation.

Yup ok