On Tue, Jan 6, 2009 at 9:23 PM, Werner Hoch <[email protected]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
