Fix hierarchical node names to be compatible with Ngspice

[mooredan]

It has been noticed that when running ext2spice with the "format ngspice" option, some hierarchical node names are incorrectly formatted. For example, here is the output for one of my designs:

• NGSPICE file created from dly_test.ext - technology: scmos

C0 vdd node1 3.02fF
C1 dly_c_0/n2 vdd 141.80fF
Xdly_c_0 node2 node1 vdd vss dly_c
Xinv_c_0 node1 a vdd vss inv_c
Xsubc_2_0 vdd vss subc_2
Xnand2_b_0 zout node1 node2 vdd vss nand2_b
C2 node1 vss 7.41fF
C3 vdd vss 22.02fF
C4 dly_c_0/n2 vss 205.61fF $ **FLOATING

Please note the "dly_c_0/n2" node on C1 and C4. I believe that the intent is to connect the two capacitors between vdd and vss to the n2 inside of the Xdly_c_0 instance. This is not what occurs. The name of the node should be "Xdly_c_0.n2"

What put me onto this was a warning message from Ngspice which then resulted in a failed transient analysis:

Warning: singular matrix: check nodes dly_c_0/n2 and dly_c_0/n2

If properly formatted, then the simulation runs to completion.

[RTimothyEdwards]

I am not so sure about this one, because, e.g., "dly_c_0/n2" is supposed to be a net name in the cell, not a reference to a net name in the child cell. I'm a bit concerned that if I "correct" it by treating it as an actual hierarchical name in ngspice, then I am missing the real problem, which is that magic has failed to put a "merge" statement in the .ext file merging this net with the net in the child cell to which it is connected. A reproducible example would be helpful (if you still have it around. . . it's been a long time for me to come back to revisit outstanding issues and pull requests).

[mooredan]

zip archive contains three files: dly_test.ext, dly_test.cir, ext2cir

ext2cir is a wrapper around magic that converts a .ext file to a .cir file -- look inside for options to ext2spice that are used

If needed, I can provide the .mag files. ...and the other .cir files that allow for reproducing the Ngspice warning

tmp.zip

[mooredan]

A more complete test case including source .mag files and ngspice simulation set up -- take a look at the README
tc1.zip

[RTimothyEdwards]

All right, finally looking at your posted example.
The problem I see here is that this error looks to be specific to your way of generating the output netlist files. If I use the ext2spice option "hierarchy on", what happens is that dly_c gets an extra (implied) port "n2" (along with "n1", etc., as all points that couple require additional ports to the subcircuit). The top level node "dly_c_0/n2" is just that---a top level node, and it is passed to "n2" in the call to dly_c. If I flatten the netlist (hierarchy off), then obviously the condition can't arise because everything is flattened into one circuit and one file. Because you extract each circuit individually, only the declared ports are specified for dly_c (in its own file), so "dly_c_0/n2" (in the top level) is, effectively, an "orphaned" node.

The more I look at this example, the more confused I get. You have a top level circuit "dly_test.cir" that contains subcircuit calls but no subcircuits. I can't think of any way that this file can be made except for the command option "ext2spice subcircuit descend off". But the default is "on", and you have not applied this option in your script. Without that option, you should either get a hierarchical netlist with all the subcircuits in it, or else a flattened netlist. Either the option is set somewhere I didn't see or is set by some combination of other options (if so, that could be an error).

If I can understand how the way your extraction is making each subcircuit into an individual file, then I think your solution is valid but needs to check the option flags. If "subcircuit descend off" then all hierarchical names in the output file should follow the ngspice syntax so that those nodes are valid nodes and not floating. But---if this method is not restricted to that specific mode, then there will be conflicts between the nodes like "dly_c_0/n2" which are not intended to be hierarchical, if you suddenly make them hierarchical.

So a little more investigation is needed, but I see the need for this patch in the case where hierarchical names are output in the context of a file that does not contain any subcircuit definitions.

[mooredan]

This should be reproducible on your end. Please take a look at the README. I unzipped the file, sorry, I found that a environment variable definition is missing. Please add this line to the source_me_env file:

export TECH="$(pwd)/tech/SCN3ME_SUBM.30.tech"

...source the source_me_env file and run "make"

The wrapper script bin/ext2cir can be run in debug mode by adding the -d option. Here's the STDOUT output for running this on the delay_test cell:

$ bin/ext2cir -d -c dly_test
TMPDIR: /tmp/ext2cir_rEOE5
load dly_test
ext2spice default
ext2spice format ngspice
ext2spice scale off
ext2spice subcircuit on
ext2spice hierarchy off
ext2spice resistor tee on
ext2spice global on
ext2spice -d -o /home/mooredan/Downloads/tc1/mag/dly_test.cir
quit
LOG: /tmp/ext2cir_rEOE5/magic.log

Magic 8.3 revision 128 - Compiled on Thu Feb 18 10:41:32 PST 2021.
Starting magic under Tcl interpreter
Using the terminal as the console.
Using NULL graphics device.
Input style lambda=0.30(p): scaleFactor=30, multiplier=1
Contact size value ignored (using GDS generation rules).
Contact size value ignored (using GDS generation rules).
Contact size value ignored (using GDS generation rules).
Contact size value ignored (using GDS generation rules).
Contact size value ignored (using GDS generation rules).
Contact size value ignored (using GDS generation rules).
Processing system .magicrc file
Using technology "scmos", version 2001a
exttospice finished.
ERRORS: 0
WARNINGS: 0

The "ext2spice subcircuit descend" option is not being set one way or the other. The resulting .cir file is:

$ cat mag/dly_test.cir

• NGSPICE file created from dly_test.ext - technology: scmos

C0 vdd dly_c_0/n2 61.91fF
C1 vdd node1 3.04fF
C2 vdd node2 2.25fF
Xdly_c_0 node2 node1 vdd vss dly_c
Xinv_c_0 node1 a vdd vss inv_c
Xsubc_2_0 vdd vss subc_2
Xnand2_b_0 zout node1 node2 vdd vss nand2_b
C3 node1 vss 6.16fF
C4 node2 vss 2.03fF
C5 vdd vss 23.13fF
C6 dly_c_0/n2 vss 6.16fF $ **FLOATING

Although subcircuit on is being used, a subckt statement for dly_test is not being created since there aren't any ports declared in the cell.

Check out the Makefile in the mag/ directory, it contains the recipes for creating the .ext files, and then the .cir files. It calls the two wrapper scripts: mag2ext and ext2cir for cell in CELLS list.

Compiled a new version of ngspice today, and get that "singular matrix" warning which results in an obscure error.

...and thanks for merging those other pull requests, less baggage for me to carry along.

[RTimothyEdwards]

No worries, I already had figured out how to run the script and could produce your result.
It is not that I thought you are setting "ext2spice subcircuit descend false" in your script. It's just that it has somehow been set in spite of you not setting it, as observed from the way the output was generated. Because the output only contains the circuit for "dly_test" and does not contain the subcircuit definitions for "dly_c", "inv_c", "subc_2", and "nand2_b". The "subcircuit descend false" is supposed to do that; it was designed mainly for standard cell designs where you presumably have the subcircuits defined in a library file somewhere and would want to just include that library file rather than dump the contents of all the subcells into the netlist. Normally the subcells would all be dropped into the same output netlist as the top level. The way your script does it is fine, but it's under that circumstance that any hierarchically-derived node name with slashes in it is guaranteed to be unconnected to anything in the output file. So one solution would be to prevent the "descend false" flag from getting set unawares like that; however, it's still a valid setting and your example shows how the output can end up incorrect because of the setting. And your solution is very clever, even though it only works for ngspice (maybe. . . I don't know how other versions of SPICE treat hierarchical names like that. Anyway, I only really care about being ngspice-compatible).

Bottom line is, I will fix this; I may end up breaking your script if I find that the inadvertent setting of "subcircuit descend false" is broken behavior and should be fixed, but I can implement the fix, and you can add the "ext2spice subcircuit descend false" line to your script if you want to keep it working like it is now.

[RTimothyEdwards]

Upon investigating the code, this is extremely hard to implement in a completely consistent way. I still think it can be done, but it would take some work to figure out how to mark a node as requiring an ngspice hierarchical name because it is inside a subcircuit that is not going to be output in the same file. My suggestion to you is either to use "ext2spice hierarchy on" so that you get all subcells output in one file (with the names correctly referring to a local name only), or use "ext2spice subcircuit off", so that it flattens all the subcircuits instead of making calls to them. If neither of those options work for you, I can look into this further when I have some time. I cannot implement your fix as-is because it will break the netlist output for all standard use cases.

[mooredan]

The intent is as you mentioned in the previous comment, a standard cell flow in which there would be a "library" of subcircuits for the standard cells. Cadence's Spectre does support the hierarchical names as well. Somewhere in the back of my mind tells me that this methodology would be useful for extraction of cell-based (not flattened device-based) SPEF, which then could be applied on a schematic-based netlist, or used as input to static timing analysis.

I'm not dead in the water as the hack does what I want in my situation, and I could always fall back on flattened or full extraction/netlisting.