gEDA: Re: Unconnected pins with spice-sdb

[John Doty <jpd-at-NOSPAMwispertel_dot_net>]

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.
jpd@wispertel.net