On Jan 1, 2006, at 9:36 AM, Stuart Brorson wrote:
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.)
No-connects are usually *not* errors. The case in question here
involved several Q/ flip-flop outputs that found themselves shorted
because I only needed the Q's. A no-connect symbol is just schematic
clutter: isn't an unconnected pin obvious?
Note that in the same design, I had a floating net problem that
neither a no-connect test nor a DRC could find: the net was
connected, but not to all the places it needed to be! At least for
mixed-signal stuff, these things tend to cry wolf and ignore the
bears.
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.
Option 3 is the best, I think. If you really want to check
unconnected pins, "grep unconnnected_pin" could get you a report.
For options 2 & 3, gnetlist can additionally emit a warning if a
dangling pin is found.
gnetlist is already too chatty: with a hierarchial design a "make"
that invokes a bunch of gnetlist's can generate hundreds of lines of
boilerplate. It can be hard to see error messages in all that stuff.
Any thoughts about these alternatives? I am leaning towards
option 3,
but would be interested in hearing the thoughts of others.
Stuart
John Doty Noqsi Aerospace, Ltd.
[EMAIL PROTECTED]
