Hello -- > spice-sdb connects *every* unconnected pin in a schematic to a net > called "unconnected_pin", thus shorting all such pins together! The > work-around is easy: to each unconnected pin, draw a short net > segment with no other connection. However, this could cause confusion...
OK, I have looked at the issue John Doty raised w.r.t. unconnected pins. The issue lies not in spice-sdb (or in any Scheme backend), but rather in gnetlist's C stuff, specifically in s_net.c:s_net_name(). When s_net_name finds an unconnected pin, it returns the string "unconnected_pin". Interestingly, when s_net_name finds an unnamed net, and it is in SPICE mode, it returns a node number. The node number counter continually increments as new nets are found. The question is: What should gnetlist do when it finds an unconnected pin? Here are some possibilities: 1. Gnetlist can return an error. I don't like this alternative, but it should be considered. After all, we do have the no-connect symbol for use in situations like this. (However, it has its own problems.) 2. In SPICE mode gnetlist can treat an unconnected pin like a dangling net. In this case it will increment the node counter and emit a node number just as if it found a dangling net. In normal mode, gnetlist can just emit "unnamed_net45" or some such string, just as it currently does for dangling/unnamed nets. 3. Gnetlist can keep separate counters for unnamed nets and dangling pins. In this case, gnetlist can emit "unconnected_pin67" (for example) when it finds a dangling pin, but would emit "34" or "unnamed_net34" (depending upon mode) for the next unnamed net it finds. Note that this behavior will tip off the user that he has an unconnected pin. For options 2 & 3, gnetlist can additionally emit a warning if a dangling pin is found. Any thoughts about these alternatives? I am leaning towards option 3, but would be interested in hearing the thoughts of others. Stuart
