text ending with "!" drops the "!" when netlisted

[d-m-bailey]

magic 8.3.546 text with a trailing ! is extracted as is, but the ! is dropped during netlisting.

Siemens Calibre uses a trailing ! to indicate virtually connected nets. However, I'm not sure if the Calibre compare routine matches all combinations of foo and foo!.
Many tools use the trailing ! to indicate a global net (which might imply a virtual net). (Calibre can use net names with a trailing : and the VIRTUAL CONNECT COLON YES directive to connect virtual nets. @H-Ojiro thanks for the correction.)

netgen reads the net name as is and keeps the !

Test case is a simple ihp13g2 process inverter.

There are 2 layouts and 2 netlists: one of each with VDD, VSS and one of each with VDD! and VSS!.

The test program compares the 4 combinations.

Expected result (with no special handling for !):

layout	netlist	result
VDD	VDD	match
VDD!	VDD	unmatch
VDD	VDD!	unmatch
VDD!	VDD!	match

Actual result:

layout	netlist	result
VDD	VDD	match
VDD!	VDD	match
VDD	VDD!	unmatch
VDD!	VDD!	unmatch

testcase_magic_netgen_pgnet_notation.tgz

tar zxf testcase_magic_netgen_pgnet_notation.tgz
cd testcase_magic_netgen_pgnet_notation
./run_lvs_test.sh

Note: most of the test case development was done by @H-Ojiro

Do we want to match Calibre?

magic would need to virtually connect nets ending in ! and netgen would need to ignore ! when comparing nets.

In that case the expected result would be:
Expected result (with special handling for !):

layout	netlist	result
VDD	VDD	match
VDD!	VDD	match
VDD	VDD!	match
VDD!	VDD!	match

[RTimothyEdwards]

The behavior with respect to trailing "!" has been in magic for a long time.

Usually trailing "!" indicates a global net. As such, I generally don't like it at all because it is a non-physical entity that can only get you into trouble.

Recently I was trying to get magic output to match CDL netlists from IHP. For that, there's now a "ext2spice format cdl". The trailing "!" are kept in that case, and a ".global" line is added to the netlist output.

I have absolutely zero interest in matching what commercial tools do unless it's a well-known, consistent behavior and documented well in the public domain. I am not aware that that's true of the use of trailing "!".

[d-m-bailey]

@RTimothyEdwards Thanks for the explanation.

As usual, there may not be a simple solution to every use case.

The ext2spice format cdl may be just what we're looking for.

However, I'd like to humbly suggest that adding a .global line to the extracted netlist is not what you want to do. For example, two separate nets with the same vdd! text do not magically become connected in the layout.

I have absolutely zero interest in matching what commercial tools do unless it's a well-known, consistent behavior and documented well in the public domain. I am not aware that that's true of the use of trailing "!".

I was mistaken. As you mention, the trailing ! means that the nets are intended to be global in the simulation netlist. (Again, I don't think this applies to the extracted layout). Separate nets that will be connected at a higher level can optionally be indicated by a trailing : in calibre (or explicitly listed in the rule deck), but as you say, that's not well documented in the public domain.

One of the problems with global nets in standard cells appears when there are multiple power domains. Calibre has an option LVS SPICE OVERRIDE GLOBALS YES (or something close to that), which allows non-global signals on instances to be preferred over global signals used as subckt ports. Verilog has no concept of global signals, does it?

[RTimothyEdwards]

@d-m-bailey : Well, technically it is exactly what I wanted to do because my goal was to match the CDL output provided by IHP. What I was thinking of was implementing ext2spice format cdl [options. . .] which could then be used to fine-tune the behavior, which is critical given that there seems to be an overly broad set of definitions for what CDL is. This could be extended to other formats like ext2spice format ngspice to change the specific handling of aspects of the circuit output.

Verilog is complicated enough that I would not dare to say what it does or doesn't support.

[d-m-bailey]

@RTimothyEdwards I'm having trouble thinking about a use case where a .global line is useful/valid in an extracted netlist.

Consider the case where there are unconnected global nets at the same level of hierarchy. When extracting with the extract unique option, would one of these nets be converted to the base signal plus _uq0 or are global signals considered implicitly virtually connected regardless of the extract unique setting?

Also consider the case of a row of standard cells that are not connected to power in the top level. Since the power definitions in the standard cells are global signals, if the extracted netlist contains a .global statement for the standard cell power signals, netgen will compare these as connected to power and pass LVS when actually they are not.

Am I misunderstading something?

[RTimothyEdwards]

I don't think .global is appropriate for any netlist related to layout. I'm just trying to produce output that matches netlists provided by foundries that don't share my opinion about global nets.

[d-m-bailey]

I don't think .global is appropriate for any netlist related to layout.

Are you saying that you feel*.global is not appropriate for the LVS source netlist also?

[RTimothyEdwards]

Exactly. But it's the foundries choice unless I can convince the foundry otherwise.

[d-m-bailey]

I think *.global can be used in the source netlist generally without problems. What concerns do you have?

[RTimothyEdwards]

My problem with it is that in reality there is no such thing as a global net. Substrate is the sole possible exception, and even then there are plenty of reasons not to treat substrate as global.

[d-m-bailey]

@RTimothyEdwards I agree with you completely. By in reality, you mean the physical design, right?

Using a global net on the source side is a way to simplify schematic entry by not having to put the power/ground pins on each hierarchy. It doesn't work well with multiple power domains that use the same standard cells, but I don't think that makes it inappropriate for all designs.

[RTimothyEdwards]

@d-m-bailey : As a chip designer, I only ever do schematics which are intended to be layouts, or could potentially be layouts. A schematic that is representing a layout is representing a physical structure and therefore should also never use global nets. I could cut corners by introducing a global net, but then if I wanted later to do a proper LVS, I haven't done myself any favors by putting the global net. For the record, though, I am talking about layout, specifically. Netgen, for example, will parse a .global out of a schematic and is supposed to be able to "localize" the global net throughout the circuit hierarchy. That doesn't mean that I think it's a good idea, but I'm just expressing my own opinion here.