Here is an issue related to extraction to ngspice: Extracting a "Caravan" project yields a .spice file about 1000 lines long, including the two lines below. The issue is "**FLOATING" in the first line. In the Caravan wrapper: C187 ip_bar_0[2]/ip_cgn_0[4]/Clx io_analog[10] 2.01f **FLOATING In subcircuit ip_cgn: C1 Clx GND 2.01f As humans, we see magic attempting to extract capacitance between node Clx and GND. Unfortunately, a different naming convention is used in the top-level Caravan file and the cell or subcircuit called ip_cgn. The diagram attached (mixed Magic and Powerpoint) shows the context. The dash-dot line is a boundary between the Caravan wrapper and a subcircuit. The node io_analog[10] is an input port to the wrapper that connects to the subcell in the upper-left through a port named GND. The other net is Clx, which is entirely local to the subcell and highlighted (white outline) in the diagram. The red-text "dielectric" in the diagram is the location of the capacitor between these nodes. The m2 lines extend a long way below the bottom of the image. As humans, we recognize "ip_bar_0[2]/ip_cgn_0[4]/Clx" as notation for accessing Clx two levels down the hierarchy. While ngspice netlists allow '/' in node names, they are interpreted as ASCII rather than a directive to descend the hierarchy. While the actual Clx node is not floating, as far as ngspice is concerned there is a floating node whose name might as well be 28 random characters.

The way to fix it is to flatten the cell before extraction. However, I don't know how LVS works.

@Erik DeBenedictis: The choice of "/" is purposeful because magic is supposed to insert ports down the cell hierarchy to account for all downward connections rather than rely on a naming convention that is (I think) unique to ngspice. It may have gotten confused here, which should be treated as an error and reported on the magic github tracker. As Luis said, a good workaround to issues of magic failing to properly extract a hierarchical circuit is to (temporarily!) flatten it for extraction using the

flatten

command to create a new, flattened layout, loading that layout, and extracting it.

Tim, thank you for that reply. I would not have guessed that answer.

I'm not sure it's possible for magic to tell the difference; it's method of finding "floating" nodes is to flag each net that is connected to a terminal of a device. After all devices are output, any net that isn't flagged is considered floating.

Hello Tim: I believe I can explain how to find these errors in the .spice file with a text editor. Magic writes out the .spice file, so all the information is available to the extractor. See screenshot. C102 is a proper parasitic capacitor and it has two node names "ip_q2n_1[5]/Cl" and "GND". Ngspice has no conception of arrays or hierarchy, so [ ] / are just ASCII characters. Node name "ip_q2n_1[5]/Cl" occurs in two other places in the file (orange highlight) because it passes signal Cl between two subcircuits. Everything is OK here. The problem is C109's node name "ip_cgn_0[4]/Clx". This string only occurs once between ".subckt" and ".ends" (when I search the full file, which is much more than the screenshot). So the problem is that "ip_cgn_0[4]/Clx" is a node name that does not have a corresponding node, which is one degree more vicious than what you described as a node not attached to a device. (A Clx node does exist, but only in a subcircuit.) The following would be a huge hack, but might give you an idea: Before outputting "**FLOATING," the extractor could search the subcircuit for the node name as a text string. If it is not found, it is one of the hierarchy naming errors we've been talking about. Erik