gEDA: Re: Unconnected pins with spice-sdb

[sdb-at-NOSPAMcloud9_dot_net (Stuart Brorson)]

Hello --

I have just updated gnetlist in CVS to implement option 3 as outlined
below.  I encourage all interested parties to grab it out of CVS and
try it out.  

I am very interested in hearing from others using the
various backends, not just spice-sdb.  The reason is that I had to
make several changes in many places to accomodate the change.  I have
tested spice-sdb, gsch2pcb, drc2, and have run the tests in the
gnetlist/tests dir, all successfully.  However, I firmly believe that
one cannot ever test software enough. . . . .

Stuart



> 
> 
> On Jan 1, 2006, at 11:07 AM, Stuart Brorson wrote:
> 
> > Thanks for your thoughts.
> >
> > Since you and I agree that option 3 is the best, that is probably what
> > I'll do.  However, I'd like to hear from Ales and/or some of the other
> > developers.  Unfortunately, seul.org seems to be down right now.  I'll
> > wait a few days for seul.org to come up and see if any other responses
> > come in.  Then I'll implement the fix.
> >
> >> 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!
> >
> > Ummm, was this a gnetlist bug, or user error?  If it was a gnetlist  
> > bug
> > I can look at it if you send a schematic exhibiting this problem.
> 
> User error. I imported some of Professor Ikeda's OpenIP subcircuits  
> (http://research.kek.jp/people/ikeda/openIP/), but they take some  
> translation. In particular, they're designed for split supplies, but  
> I'm not doing that, so I had the translation script change all the  
> "Vss" nets to 0 (but I missed one).
> 
> The point was that automatic checking doesn't seem very effective to  
> me. Complains about the wrong things, and it's hard to see how it  
> could detect problems like the one I had. Had to page through a  
> "print all" from a SPICE "op" analysis, looking for strange node  
> voltages. Found the short circuit problem that way, too.
> 
> >
> > Thanks for the bug report!
> 
> Thanks for the software! Much nicer than Viewlogic/PSPICE for the  
> stuff I'm doing.
> 
> >
> > Stuart
> >
> >
> >
> >>
> >>
> >> 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
> >>
> >>
> >>
> >
> >
> 
> John Doty              Noqsi Aerospace, Ltd.
> jpd@wispertel.net
> 
> 
>