[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: A little puzzled about the purpose of gschem



On Apr 28, 2010, at 12:34 PM, Madhusudan Singh wrote:

>   Thanks for a reasonable response to my post.
> 
>   Yes, an initial investment is often needed, but that ought to be an
>   investment that deals with non-standard components that are not of
>   common interest.

Well, you started out complaining about a 741 model. I'd call that a very rare, obsolete part: I haven't actually seen one in a circuit in over 30 years. I guess it's still in textbooks (read Stephen J. Gould's rants about textbook authors' tendency to copy from previous textbooks sometime), but why would anyone use it in a new design?

You and I probably cannot agree on what components are of "common interest", and if we bring in a third party I'd expect yet another completely different viewpoint.

> Second, before your response, no one (at least as I
>   read it) said that you could save the spice directives with the symbol
>   itself. People talked about copying and pasting things from an existing
>   schematic, but that is not the same thing.

gEDA is, above all, very flexible. There are a number of ways to accomplish most tasks. You seem to have found one of the more difficult ones (but I still don't understand your difficulty).

> 
>   This rekindles my interest in gschem. One followup question - is it
>   possible to pack symbols with commonly used public domain spice models
>   and create a library that other users of gschem can employ (and would
>   then be able to use without all that initial investment of time) ?

Sure. The jargon is "heavy symbols".

> If
>   yes, why has no one ever done it (the project is pretty mature) ?

1. It would take a huge library of symbols to satisfy everybody's desire for their own version of "components of common interest".

2. There are few "commonly used public domain spice models", so the library would necessarily be very incomplete.

It's free software. Someone would have to volunteer to do this. I suspect nobody has because anybody who could actually do it understands the massive size of the library that would need to be generated, and the lack of freely publishable models.

> If
>   no, what are the legal / technical reasons for that choice ?

You are welcome to contribute here. Get DJ to give you an account at gedasymbols.org. Your ambition is impossible, but partial success would still be valuable progress. Beware that DJ will be vexed with you if you pirate intellectual property: be sure you violate neither the model owner's license terms nor the GPL's restrictions on compatible licensing.

> 
>   Its not just LTSpice. kicad (not that I have used it, but reading from
>   the descriptions) supposedly also does a more seamless spice simulation
>   AND has pcb layout tools integrated.

They also can't go most of the places gEDA can go. Perhaps you don't care, but gEDA's flexibility is essential to me. Nobody does VLSI design with LTSpice or kicad. Nobody captures schematics for symbolic circuit analysis with them either. But gEDA can do those things.

Type "man gnetlist" for a glimpse at the variety of data products gEDA can export (and it's easy to add more with user Guile scripts). What other toolkit can do this?

> 
>   Not embedding the commonly available spice models for common components
>   appears to be a retrograde choice for gschem.

Most commonly available models cannot be legally embedded in distributed symbols since most have restrictive licenses.

Note that for big, complex simulations, embedding models in symbols is undesirable because it places a separate copy of the model in the simulation for each component instance. ngspice, at least, handles a reference to a single instance of a library model much more efficiently than a copy of the model for each component instance. In extreme cases I've even seen this problem reveal memory management difficulties in ngspice, resulting in segfaults. But for small, simple simulations, you may prefer models embedded in symbols. gEDA can handle this either way: that's the kind of advantage flexibility brings.

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