El mié, 05-04-2006 a las 12:29 -0600, John Doty escribió: > On Apr 5, 2006, at 11:41 AM, Stuart Brorson wrote: [snip] > > I'd personally prefer that the DRC simply not report unconnected pins > > -- a usually harmless thing -- than encourage a practice which can > > inadvertently lead to bad boards simply to pass a DRC. The DRC is > > supposed to prevent errors, not cause them! Perhaps disable this > > feature until the appropriate fixes are rendered in the netlisting > > backends and in gsch2pcb????
As that feature disable only will come out in CVS or in the next geda release, the harm is done. So by then, I'd prefer to have it fixed. By now, the user can simply keep the pin unconnected and disable that DRC check. See: http://geda.seul.org/dokuwiki/doku.php?id=geda:faq-attribs#i_want_to_disable_some_of_the_schematic_drc_checks._how_can_i_do_it > DRC is perhaps useful for large digital designs, but it is more > trouble than it's worth for small analog designs. The pintypes are > designed for digital, and often it isn't obvious what pintype you > want in analog. For example, for current mode interfaces the rules > about connecting inputs and outputs in parallel are reversed. There's > no way to distinguish between power *sources* and power *sinks*. Of > course you can designate everything passive, but then it's useless > (and that's still extra work). Current pintype attributes are defined in the same way as commercial packages I've seen. What I also miss is the "power source" or "power sink" pintype. Adding them to the DRC is fairly trivial, and also to the docs. Would it be better to have pwr_in and pwr_out pintypes? > Despite these limitations, gnetlist does a hard sell for DRC, as if > it was going to find lots of common problems when it really only > finds a restricted subset. We have newbies sweating to get DRC to > work for things like power supplies. That's silly. Even for analog design, I prefer a restricted DRC checking than no DRC checking.... Now some thoughts to discuss: I've taken a glance at the gnetlist code, trying to find a way: - quite easy to code. - which doesn't change the current behaviour. As Dan pointed out some time ago, the NoConnection symbol could have the graphical=1 attribute, so it won't get to the netlist, as it is currently done. Suppose the device=DRC_Directive and value=NoConnection are also added. It can't have the refdes attribute. gnetlist can build a graphical object netlist independent of the current netlist, just slightly modifying s_traverse_sheet (I hope). Then, a new graphical object search function with parameters: - the netlist name where the graphical object is connected to. - an existing attribute of the graphical object (i.e: "device=DRC_Directive") - the desired attribute (i.e.: "value") will return a list with pairs with: - the desired attribute (i.e.: "NoConnection") - the pin of the graphical object connected to the net. I'm not so sure about this one. It is not needed for DRC directives, but it could be for other things I'm not aware of. Since there are no refdes in the graphical symbols, they haven't any unique name, so the pinname may be useful. This way the DRC checker can search for DRC directives before reporting the error. Currently we are talking about the NoConnection directive. Are there more desired directives? I would like to hear your opinions so, please, speak! Regards, Carlos
