What is _net0?

The spectre netlister (not just the spectre netlister, but all ADE netlisters) will map any net names which are reserved words in spectre, or are already used for some other purpose, or contain illegal characters. The illegal characters usually just map the characters within the name but reserved words and already used names get mapped completely.

My guess is that your extracted view has a node called "0" in it (maybe to try to reference the global ground). The node "0" has no special meaning in Virtuoso's namespace, and is just a node like anything else - it does not mean the global ground, as it does in SPICE. Since in ADE the node gnd! gets mapped to node 0 in the spectre netlist, it would be a mistake if node 0 in a schematic or extracted view also got netlisted as 0, because then  you'd have two distinct nodes in the Virtuoso database appearing in the simulator as being connected.

There was a bug in the spectre netlister in IC615 where node 0 in an extracted view was not being mapped, but that was corrected - it also showed up if you used QRC and specified "0" as the reference node, thinking that it meant the global ground.  

Mapping itself is not a problem - if you probe a net in your schematic or extracted view, the mapping allows ADE to know what it ended up as in the netlist and the right node got plotted. 

Of course, it might be some other reserved word, but it sounds quite likely to me that it would be node 0. I can't really answer about StarRC since I'm not familiar with it as it's a Synopsys product, but if it's that, maybe StarRC has some way to specify the reference node for capacitors which are lumped to ground? If so, setting it to a suitable node that is in your actual circuit would be the wise thing to do.

So as I said, mapping isn't an issue in itself, but might be if you were expecting node 0 to be a global ground. The netlister is doing the right thing to preserve the integrity of the connectivity here, but it might not be what you want, in which case you might need to alter the StarRC setup.

There are SKILL APIs to look at the mapping, but not sure that's going to help here (and I can't remember them off the top of my head, since I'm not responding from a work computer). If you get stuck, you could contact http://support.cadence.com and we can take a look at your data to spot the problem (assuming it actually is a problem!) 

Regards,

Andrew. 

The spectre netlister (not just the spectre netlister, but all ADE netlisters) will map any net names which are reserved words in spectre, or are already used for some other purpose, or contain illegal characters. The illegal characters usually just map the characters within the name but reserved words and already used names get mapped completely.

My guess is that your extracted view has a node called "0" in it (maybe to try to reference the global ground). The node "0" has no special meaning in Virtuoso's namespace, and is just a node like anything else - it does not mean the global ground, as it does in SPICE. Since in ADE the node gnd! gets mapped to node 0 in the spectre netlist, it would be a mistake if node 0 in a schematic or extracted view also got netlisted as 0, because then  you'd have two distinct nodes in the Virtuoso database appearing in the simulator as being connected.

There was a bug in the spectre netlister in IC615 where node 0 in an extracted view was not being mapped, but that was corrected - it also showed up if you used QRC and specified "0" as the reference node, thinking that it meant the global ground.  

Mapping itself is not a problem - if you probe a net in your schematic or extracted view, the mapping allows ADE to know what it ended up as in the netlist and the right node got plotted. 

Of course, it might be some other reserved word, but it sounds quite likely to me that it would be node 0. I can't really answer about StarRC since I'm not familiar with it as it's a Synopsys product, but if it's that, maybe StarRC has some way to specify the reference node for capacitors which are lumped to ground? If so, setting it to a suitable node that is in your actual circuit would be the wise thing to do.

So as I said, mapping isn't an issue in itself, but might be if you were expecting node 0 to be a global ground. The netlister is doing the right thing to preserve the integrity of the connectivity here, but it might not be what you want, in which case you might need to alter the StarRC setup.

There are SKILL APIs to look at the mapping, but not sure that's going to help here (and I can't remember them off the top of my head, since I'm not responding from a work computer). If you get stuck, you could contact http://support.cadence.com and we can take a look at your data to spot the problem (assuming it actually is a problem!) 

Regards,

Andrew.