Re: gEDA-user: Blind and buried vias?

[John Doty <jpd@xxxxxxxxx>]

On Sep 28, 2009, at 3:08 PM, Dan McMahill wrote:

>
> Can we put an end to this thread?  How about this.  PCB is part of  
> gEDA.
>   I'm a developer for both.  It is not a part of gaf (gschem and
> friends) but it is the most popular reason for using gaf.  You can  
> argue
> all you want about exactly how much a part of gEDA PCB is, but it is a
> part.  Some times I work on gaf and PCB totally independently, some
> times I literally have had one emacs open with gschem source code and
> another with pcb source code.

That frightens me.

>
> Integration is not a bad thing but integration when done in a way that
> precludes using the tools in a non-integrated matter is bad and as far
> as I know *none* of the actual developers of any of the various tools
> falling either directly under the gEDA umbrella or in its drip line  
> are
> proposing integration in ways that preclude the toolkit nature.  I  
> also
> don't think any of the actual developers need constant reminding of  
> this.

"To the man with a hammer, everything is a nail". I can think of  
three gEDA problems that have resulted from developers being scenario- 
driven rather than thinking about the general case. Each one has cost  
me. I'll go into the details in private email if you like.

>
> I will say that there are some very powerful features that you simply
> can't achieve without integration but that integration can, should,  
> and
> if we ever get that far, will be done in a more generic way.  For
> example, at one point I had gschem schematic <-> pcb layout cross
> probing working.  Click on a schematic instance and pcb selects the
> corresponding layout instance.  Click on the layout instance and  
> gschem
> selects the schematic instance.  In fact that code still exists in pcb
> and gschem as far as I know.  The only place where gschem knew  
> about pcb
> was via a single scheme file which was loaded at run time.  All of the
> other code which was written to make this possible was totally generic
> and is there to benefit whatever other tool flow is desired.

That's a good thing. if true.

>
> No matter how you slice it the largest user base of gschem is using it
> for driving pcb and so it makes a lot of sense to talk about new
> features in the context of pcb.

"Prediction is very hard, especially about the future."

>   Did I need to use pcb when trying to
> extend the scheme capabilities of gschem?  Of course not, but why not
> use the vehicle that is likely to see the most use.  Besides which,  
> this
> is a volunteer project and developers are going to use the portions  
> that
> are useful to themselves as the vehicle.  It doesn't mean we don't  
> care
> about making sure the tools remain flexible.  I certainly don't speak
> for all the gschem developers but I suspect that gschem would have  
> died
> long ago if it weren't for the pcb user base.  I would wager the break
> down is probably 70% of gschem schematics are to drive pcb, 10% for
> schematics for papers in school or journals, 15% for simulation,  
> and 5%
> for everything else.  Doesn't mean we don't care about the 5, doesn't
> mean we need continual reminders of it either.

"To the man with a hammer, everything is a nail". Yes, the developers  
do need reminders.

>
> gaf could also benefit a lot from having the power needed to provide
> tighter simulation integration too.  It is really nice to be able to
> click and plot a node or back annotate dc node voltages or device
> operating points on a schematic.  It doesn't need to be done in a way
> that forces this work flow and again, no one who is actually writing
> code for the various tools is proposing that.

But complexity *always* bites the user. KISS, especially at interfaces.

>   What I have seen though
> is numerous arguments of this type turning off some very capable  
> people
> and actually hurting the progress which is needed to build on the
> toolkit nature of these tools.

You think misrepresentations like "gEDA can't do buried vias" aren't  
harmful to gEDA? How about "gEDA can't do ASIC design"? Where did my  
working video digitization silicon come from, then? Both statements  
are equally true. gEDA can do neither buried vias nor ASIC design *by  
itself*, but its biggest strength is working with other tools.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user