Re: gEDA-user: Wish list, sort of

[r <nbs.public@xxxxxxxxx>]

On Tue, Jan 6, 2009 at 9:23 PM, Werner Hoch <werner.ho@xxxxxx> wrote:
>
> The [GLOBAL] section defines some pathnames, ...
>
> All other sections are attributs of devices, where all attributes and
> values for the symbol are defined.
>
> With the get command gschem can ask for a symbol. The python script will
> then put the values of the requested symbol section into a symbol
> template. (using the python moduls string.Template and ConfigParser)
>
> The script writes the complete symbol to stdout and gschem receives the
> symbol.

So it's like a parametrized cell. Nice.

> Why would you like to store schematics in that database?
> Or Netlists?
> Sounds strange to me.

A cell is much more than just a symbol. Look at "electric" (it's on
GPL btw) http://www.staticfreesoft.com/ (I don't advocate a
"binary-blob type database" here - using text files in directories is
perfectly fine for me) - it has libraries, which contain cells, which
consist of multiple views (symbol, schematic, layout and so on). Other
tools often include netlister specific views, like *spice, cdl,
verilog, vhdl, etc. The whole hierarchy is not tied with attributes -
most design tools have a notion of hierarchy configuration ("let's
simulate this circuit with this cell extracted from the layout,
instead of a schematic").

Sure I can do this with make, but this lefts gschem completely unaware
of the design hierarchy (or, worse, it can get it wrong if there is a
mismatch between "source=" attributes and the makefile). A potential
solution (or workaround, depending how to look at this) would be a
tool, similar to yours, that based on a configuration or a convention
dynamically overwrites the symbols so that gschem knows where to get
their schematics from.

Regards,
-r.


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