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. Thanks for the bug report! 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] > > >
