[SOLVED] Why don't the components in the schematic appear in the netlist?

[xiaowenrun]

Hello everyone
My question is like the title. I don't know if you've ever been in a similar situation. This is not the case for all kinds of components. There is no problem with the transistors, but when I add a resistor, no matter what kind it is, it won't appear in the netlist, but it does in the schematic.

 

[FvM]

Forgot to mention your design tool.

 

[xiaowenrun]

Forgot to mention your design tool.

Thanks. You are right. I am using IC6.1.7. I placed many kinds of resistors of a CMOS technology in a schematic. But when I checked the netlist, I couldn't see any of them.

 

[KlausST]

Hi,

Did you connect the resistors somehow?

--> show your schematic

Klaus

 

[dick_freebird]

Some tools allow properties or netlist procedures to ignore a component at netlisting. And what kind of netlist then matters.

For example in Cadence you can add a "lvsIgnore = 't' " property to any instance and make it disappear from the schematic netlist for LVS - but Spectre netlist would still include.

Parasitic and generic resistors do this at the cell level because they are not appropriate to on-chip-only LVS.

 

[xiaowenrun]

Hi,

Did you connect the resistors somehow?

--> show your schematic

Klaus

Klaus

I haven't solved that problem yet. But that problem does not only occur in a specific circuit structure.

Wenrun

--- Updated Sep 14, 2022 ---

Some tools allow properties or netlist procedures to ignore a component at netlisting. And what kind of netlist then matters.

For example in Cadence you can add a "lvsIgnore = 't' " property to any instance and make it disappear from the schematic netlist for LVS - but Spectre netlist would still include.

Parasitic and generic resistors do this at the cell level because they are not appropriate to on-chip-only LVS.

Thanks. I placed resistors from analogLib and resistors from the technology. The former appears in the netlist, but the latter doesn't. I was running a pre-simulation when I found the problem. It seems that the resistors allowed no current to flow through them. After I checked the netlist generated, I found that the resistors from that technology don't appear.

 

[dick_freebird]

In many PDKs I've used, "presistor" appears in the process
devices library. This is one that should "netlist as a short"
(making both terminals occupy the same netlist node, and
joining what look like distince nets on the drawing.


When the resistor "doesn't appear", is it also true that the two
nets drawn on either end of it, have become merged? You'd
have to wade through the netlist looking for topology-points
to key on, I guess.

But a question is, is the resistor "omitted and replaced by short"
or is it "omitted and replaced by open" (like an empty subcircuit
might do). Or some break in the include-chain that "loses" the
resistor definition?

Do you incur any warnings / errors regarding the resistors?
"Undefined", "Missing". ???

When you say no current flows, do you get a number, or NaN,
or some other thing? Can't get port currents from a missing
instance, should not even get a result ("0" is a result, even if
not credible).

 

[xiaowenrun]

In many PDKs I've used, "presistor" appears in the process
devices library. This is one that should "netlist as a short"
(making both terminals occupy the same netlist node, and
joining what look like distince nets on the drawing.


When the resistor "doesn't appear", is it also true that the two
nets drawn on either end of it, have become merged? You'd
have to wade through the netlist looking for topology-points
to key on, I guess.

But a question is, is the resistor "omitted and replaced by short"
or is it "omitted and replaced by open" (like an empty subcircuit
might do). Or some break in the include-chain that "loses" the
resistor definition?

Do you incur any warnings / errors regarding the resistors?
"Undefined", "Missing". ???

When you say no current flows, do you get a number, or NaN,
or some other thing? Can't get port currents from a missing
instance, should not even get a result ("0" is a result, even if
not credible).

What do you mean by "This is one that should netlist as a short"? If the resistor is shorted, I think the other part of the circuit can't see it.
I have done some experiments, and I found that since the nodes always follow a device in the netlist, they will not appear in the netlist if the device doesn't.
So the disappeared resistors are not replaced by anything. if one breaks a branch, you can still see the devices connected to it and the nodes.

I got this warning.
WARNING (OSSHNL-117): Ignoring switch view 'schematic' of cell 'rnwsti_ckt' in library 'smic65', as it does not contain any instance. To netlist this cell, add this switch view to the stop list or to ignore any specific instance set the property 'nlAction' to value "ignore" on this cell view.
What does it mean?

At last, the current through those resistors is 0. However, when one terminal of a resistor from analogLib is floating, the current through it is also 0.

Thanks

 

[Dominik Przyborowski]

1. What views you have available for cell?
2. Which view has been used for instance
3. What is your configuration (if you are pointing design to config view) or environment view stop list?

 

[dick_freebird]

The error message indicates that there's no valid switch-view
or stop-view associated with rnwsti_ckt.

A symbol can be traversed to another "vierw", that's its whole
purpose. There is a "switch-view list" default which will tell
Cadence to try finding its members, in order, pick first found.
List typically begins with "schematic cmos.sch cmos_sch" as
these are standard choices for hierarchy.

Then you have your "stop-view list", which is different - these are
"views that get used" by tools or the netlisting process for them.
"spectre cdsSpice veriloga" are there to serve their various
simulators (maybe cdsSpice is well and truly dead, by now).
In your case you need this rnwsti_ckt to have a spectre view or
you'll get no netlisted element(s).

Open up the rnwsti_ckt schematic (if any) and show what's
inside it. Look at it in the Library Manager and see what views
it's got. Are any appropriate to the task / simulator? Maybe this
resistor is so funky they decided to model it by veriloga, only
your stop-view list doesn't contain "veriloga". Something like that.

You might also run into problems of another sort, if rnwsti_ckt
is supposed to invoke a subcircuit model whose "guts" have
not been "included" in the simulator's file-include-chain. Like
it's hoping there's a rnwsti model somewhere in the spectre
pile, but the file holding the definition has not been sourced.
Then whatever the spectre view (or ???) said was the "PLUS"
terminal, can't be probed because that layer of the -Spectre-
hierarchy was never defined. There would ought to be some
CIW complaint about that, when you try to probe a terminal
(something along the lines of "WTF?", only in Spectre-garble).

If it appears to involve the view switching / stopping, that's a
Hierarchy Editor problem, or a basic config problem (you can
assert your own switch / stop list in (I think) either .cdsenv or
.cdsinit) and you can assert, per master or per instance, an
overriding / explicit view list and order. To take full advantage
of that, you'd need to make a config view from schematic,
then open -that- (w/ both hierarchy editor and schematic
windows) to start your simulator session from, then proceed
normally (with some added attention to what's up with rnwsti_ckt).

 

[xiaowenrun]

The error message indicates that there's no valid switch-view
or stop-view associated with rnwsti_ckt.

A symbol can be traversed to another "vierw", that's its whole
purpose. There is a "switch-view list" default which will tell
Cadence to try finding its members, in order, pick first found.
List typically begins with "schematic cmos.sch cmos_sch" as
these are standard choices for hierarchy.

Then you have your "stop-view list", which is different - these are
"views that get used" by tools or the netlisting process for them.
"spectre cdsSpice veriloga" are there to serve their various
simulators (maybe cdsSpice is well and truly dead, by now).
In your case you need this rnwsti_ckt to have a spectre view or
you'll get no netlisted element(s).

Open up the rnwsti_ckt schematic (if any) and show what's
inside it. Look at it in the Library Manager and see what views
it's got. Are any appropriate to the task / simulator? Maybe this
resistor is so funky they decided to model it by veriloga, only
your stop-view list doesn't contain "veriloga". Something like that.

You might also run into problems of another sort, if rnwsti_ckt
is supposed to invoke a subcircuit model whose "guts" have
not been "included" in the simulator's file-include-chain. Like
it's hoping there's a rnwsti model somewhere in the spectre
pile, but the file holding the definition has not been sourced.
Then whatever the spectre view (or ???) said was the "PLUS"
terminal, can't be probed because that layer of the -Spectre-
hierarchy was never defined. There would ought to be some
CIW complaint about that, when you try to probe a terminal
(something along the lines of "WTF?", only in Spectre-garble).

If it appears to involve the view switching / stopping, that's a
Hierarchy Editor problem, or a basic config problem (you can
assert your own switch / stop list in (I think) either .cdsenv or
.cdsinit) and you can assert, per master or per instance, an
overriding / explicit view list and order. To take full advantage
of that, you'd need to make a config view from schematic,
then open -that- (w/ both hierarchy editor and schematic
windows) to start your simulator session from, then proceed
normally (with some added attention to what's up with rnwsti_ckt).

Thank you for your detailed answer. I used another technology to run my simulation, so I never solved this problem. Today, I finally decided to figure it out. Your answer inspired me. I opened the schematic of the device that could not appear in the netlist and found that it was a sub-circuit, and it failed when calling another symbol. I changed the name of the library to solve this problem. I didn't expect the problem to be so simple, but I wouldn't have thought of checking the schematic of the device without your reminder. I would think there is something wrong with this library. So I really appreciate your help.