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

[asomers@xxxxxxxxx]

The problem is that there are very few public-domain spice models.
Every semiconductor vendor has their own license (sometimes several)
for their spice libraries.  Only some of these licenses allow
redistribution.  Furthermore, because the licenses are carelessly
written and applied, they are often legally ambiguous.  Yet more pain
comes from their incompatibilities; no two spice simulators are 100%
compatible, so most (in my experience) vendor-provided models do not
work with the open-source simulators.

Spicelib (http://www.h-renrew.de/h/spicelib/doc/index.html), which I
shall shamelessly plug for the 3rd time on this thread, tries to solve
both of these problems.  It is a set of scripts that a user can
download.  The scripts will fetch vendors' models directly from the
source, solving the redistribution problem.  Then it will patch them
for compatibility with gnucap and ng-spice, solving the compatibility
problem.

Spicelib is still rough around the edges, but it's a quick way to get
~1500 tested spice models that you can use.  It does not, however,
come with a set of gschem symbols.

There is no reason why someone can't create a library of symbols that
reference the spicelib models.  However, many (most?) gschem users
don't want this.  A one-size-fits-all symbol just doesn't satisfy
everyone's needs.  While it's nice for hobbyists and students, most
professionals have very detailed requirements and would be unable to
use such a premade library.  For professionals, gschem's builtin
"light" symbols are more useful, because they can be easily adapted to
specific needs.  This is also why expensive EDA software typically
doesn't come with premade symbol libraries.

But I agree, hobbyists would rejoice at the availability of such a
library.  http://www.gedasymbols.org/ is the closest thing we have
right now.

On Wed, Apr 28, 2010 at 12:34 PM, Madhusudan Singh
<singh.madhusudan@xxxxxxxxx> 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. 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.
>
>   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) ? If
>   yes, why has no one ever done it (the project is pretty mature) ? If
>   no, what are the legal / technical reasons for that choice ?
>
>   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.
>
>   Not embedding the commonly available spice models for common components
>   appears to be a retrograde choice for gschem. But I am happy to hear
>   that the symbols can be saved with the model itself. Whether or not a
>   proper shared library can be created is a different matter.
>
>   On Wed, Apr 28, 2010 at 12:23 AM, Geoff Swan
>   <[1]shinobi.jack@xxxxxxxxx> wrote:
>
>       Most tools require some preliminary investment in terms of setting
>     up
>       libraries to the satisfaction of the user, plus general
>       familiarisation. I think you will find you only need to modify
>     your
>       symbol once to include the appropriate SPICE directives. If you
>     save
>       this symbol you can then reuse it (not trying to make you suck
>     eggs
>       here but this argument seems stalled to the point of stating the
>       obvious).
>       The purpose of gschem does not include containing a library of
>     symbols
>       that include all possible spice and pcb footprint information.
>     gEDA
>       includes gattrib to ease the process of customising symbols - this
>     is
>       not the only method of adding/editing attributes though.
>       Comparing gEDA with LTSpice is a bit odd once you understand the
>       purpose of gEDA. LTSpice by definition has all the SPICE
>     information
>       for all its library components - but I'll warrent it has very
>     little
>       information about component footprints. gEDA is much more powerful
>     and
>       versatile than LTSpice but does require you to do a bit of manual
>     work
>       to begin with. There is discussion about creating a database
>     separate
>       to gschem that may in the future provide SPICE symbol data for
>     standard
>       components. Depending on how this is integrated into the workflow,
>       perhaps this would ease your concerns. Not much help at this stage
>       though...
>       All the best,
>       Geoff
>     _______________________________________________
>     geda-user mailing list
>     [2]geda-user@xxxxxxxxxxxxxx
>     [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
> References
>
>   1. mailto:shinobi.jack@xxxxxxxxx
>   2. mailto:geda-user@xxxxxxxxxxxxxx
>   3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
>


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