Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
LVS works alone but doesn't work together
Hello,
I have a problem regarding the LVS verification: it says that the hierarchical LVs are not good, but all my sub-circuits have been verified with a good LVS. I show you an example with not_opt1.
This is the first time I've had this problem, do you have any idea where it's coming from?
Comments
I don't see anything displayed that leads anywhere. If
lower level cells are indeed clean, I'd look to the connecting
nets (or their absence / missing bits).
It might be helpful for you to fully expand anything
"expandable" until you get to a specific complaint about
a specific net or instance.
I do not know what the yellow-exclamation and red-bar
"indicators" are trying to communicate. However, that
a "checked good" instance is showing what I take as
a "bad" indicator, says to me maybe a search-path
problem? Maybe SPICE netlist left to default directory,
but klayout-invoked SPICE netlisting doesn't know how
to find relative-path parts, or something?
Good news is, you don't need to look for the errors in the subcircuits.
Bad news is, you have an error. But it has to be related to something in the top level layout.
The way this can happen is for example that you attached to a subcircuit at some position that does not correspond to a pin in the schematic. This can also be short introduced by placing a wire incorrectly over the macro cell.
The red indicators say that KLayout could not correlate the subcircuit call and the layout cell. The names are matching and subcircuits are present which is already good news. You should expand the subcircuit nodes and check the pin sections first. If you find pins in the layout which do not belong there, this is a strong indication that you have a wrong connection. A missing pin is an indication that a connection needs to be made. A missing tap can also prevent the formation of a pin.
So the causes are manifold. As usual, the problem is very difficult to debug only from a screenshot.
Matthias
Okay, the issue is not with my cell, but at the top level. It is good news. I'm trying to solve these issues in subcells, and I'm becoming crazy.
I've been trying to fix this error since yesterday, but nothing has changed. Could you help me understand what is happening?
Thanks
There is a problem with V_ss, and I don't know why, whereas V_dd is okay.
Okay, I think I've found where the issue comes from. I took a screenshot of the extracted netlist, and the subcircuit is detected, but I don't know why the net $9 replaces V_ss in some places but not everywhere. I believe the problem is occurring during the extraction process.
Do you know how to correct it, or do you know how to not take into account subcircuits in the extracted netlist?
Thanks for your help.
Interesting use of $args, I would like to understand more.
The simulator I started with ('80s) had a corporate wrapper
which let me use "&1" as a literal, auto-concatenate as you
show "$1". I've been wanting a functionality like that (or to
learn how to use the argv() in a similar text-manipulation,
text-accretion way). Have you seen any ngspice documentation
which speaks to this style specifically?
This (large amount of funky special characters, and "rich
tapestry" of behaviors they invoke) is something that I think
deserves is own manual chapter and copious examples.....
I don't know if that scheme is actually supported or works
as you might believe. If it -does- then you are creating
arg-named subnets of V_ss, and maybe these are what's
breaking the V_ss (so-called).
Might try the varying "listing -" options and watch those
"argument-appended" V_ss nodes as they "evolve", and
what into.
Be sure and let us know, as (if the scheme works as shown)
there's a lot of raw power there. More, if you can use text
variables / vectors and substitutions.... But you know what
the movies say about great power....
@CMeyer Thanks for the expanded tree view. The problem appears to be a duplicate V_ss node in the layout, but a single one in the schematic.
Apparently, there are two V_ss nets inside the subcircuit which are not connected with the subcircuit, but the connection is made outside.
If you are using the same Sky130 LVS I find, it contains this statement which basically connects all identically-labelled nets for the top level cell, but not when the cell is embedded:
I assume you have two "V_ss" pins in the layout that need to be connected further up. In the corresponding schematic there is only one pin, hence the netlists do not match.
Matthias
Sorry I show you the extracted netlist not refresh. In this case there are no problems with V_ss but I don't understand the LVS result.
But the thing i don't understand, the label $6 normally is called B for the other pin name the name is correct. Do you think the problem come from here ?
This is the extracted netlist
It works !
But I wish know why I need to " connect_implicit (V_ss ) "
I am still bothered by all the passed-in connectivity (like
"Vss$1" and thinking this makes a net that somebody thinks
should be Vss, but somebody else says "huh?".
@CMeyer You should show the schematic netlist for "Nand_opt". I'm sure it only has one V_ss pin and that means there is one pin more in the extracted netlist - i.e. two places where V_ss is attached and two separated islands with V_ss in the physical layout while there is only a single one in the schematic. That will not match as the number of pins is different. Without more details I can't say much more.
"connect_implicit" solves that for you, but this option bears the risk to fake a connection that physically is not there. So be super careful!
There is an old ticket addressing this problem (https://github.com/KLayout/klayout/issues/885). I want to provide more safety for "connect_implicity", but I have simply not implemented that.
Matthias
I share your concern about "doing stuff implicitly" and my
off-the-top recommendation is to make it default to "nope!"
and require users to override willfully. Then at least the tool
is blameless. Guard against "cruft" or saved settings being
passed along over time by making these "OK, try this"
settings real time only?