@Stefan Schippers: I am finding an issue with pin ordering. It's caused by the following: My analog flow consists of creating a circuit schematic (with a symbol), then a testbench schematic, and I simulate from the testbench. I then netlist the subcircuit schematic (not the testbench), and import that netlist into magic to get all the ports and devices. The problem is that when I netlist the subcircuit by itself from xschem, it has a different pin ordering than it does if I netlist it as part of the testbench. Is there a way that I can do this that would make the pin order the same for the schematic no matter whether I extract it by itself or as part of a testbench? (Note that I always have the choice of reading the testbench netlist into magic and then discarding the cell that corresponds to the testbench. But that's a less satisfactory solution.)

@Tim Edwards I think I can verify what you’ve stated. xschem will use symbol pin ordering over schematic ordering. @Stefan Schippers has a detailed explanation about how to remedy this here.

The problem is that there is a "format" line for symbols, but that has no effect on the schematic, so then the schematic pins would all have to be annotated with the "sim_pinnumber" attributes. I feel like it would be a better solution if xschem understood that when a schematic has a matching symbol, then the symbol should be used to generate the port list (with an error being flagged if the symbol pins don't match the schematic pins). It really should not be possible (that is, should not be allowed) to create a different pin order for a circuit as the top-level vs. a circuit as a subcircuit in a hiearchical design, as long as a matching symbol exists for the schematic.

@Tim Edwards This is a reasonable suggestion. Will manage to do so. If a schematic has an existing symbol make the symbol rule for pin ordering. WIll do asap.

I try to keep my suggestions reasonable. : )

@Tim Edwards the "reasonable" suggested change has been done. If a netlist for a toplevel schematic is created the port list for the toplevel is obtained from the corresponding symbol if: • the symbol file exists • the symbol has at least one I/O port (so we avoid using "decoratve" / "container" symbols that don't have any interface pins)

Great, and thanks for the fast response!

@Tim Edwards may be some users experience differences in the produced netlists. For simulations this is not a problem (the top port lists are commented). For LVS i agree with you the current setup is more consistent. May be someone has put workarounds to fix the netlist and these workaround are no more necessary. We will see.