Re: gEDA-user: A couple o' questions

[Carlos Nieves Ónega <cnieves.mail@xxxxxxxxx>]

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