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. > >> [EMAIL PROTECTED] > >> > >> > >> > > > > > > John Doty Noqsi Aerospace, Ltd. > [EMAIL PROTECTED] > > >
