Re: Electric symbols ("icon") creation & netlisting

[Steven Rubin]

> As regards the lanuguage support, the electricLang release
> being non-GPL'd is for some kind of copyright reasons (per
> the download page). Is this true of all of the language
> options (Lisp, TCL, Java)? I guess I don't know if the
> copyright issue is the limits to charity, or some
> upstream bind. But my basic question is, if making the
> netlisting comprehend instance attributes requires the
> language capability, is one of these languages a better
> bet than the others, for eventually becoming a fully-
> integrated part of the public distribution?

The LISP and TCL code are written by others, and so that code cannot be 
distributed with my code.  GNU will not redistribute other peoples' 
works.  The Java interface is simply object code that links with 
Electric.  I certainly cannot distribute that.  In any case, all 3 look 
like they're going to be around for a while.  Choose the one you like best.

> Is the library and schematic format open enough that
> an external program could look in and netlist? Would
> a UNIX background TCL script (or whatever) be able to
> go from a schematic, plow through the hierarchy and
> maybe permit the indirected netlisting?

The disk files formats are not documented nor does it make sense to build 
external programs that read them.  However, a piece of code (C, LISP, TCL, 
or Java) can be linked with Electric to examine and netlist the 
database.  This code cannot be a "UNIX background script" because it must 
be run as part of Electric.  But yes, it could examine a schematic and 
perform arbitrary netlisting.

> Is there a chance that the library structure will be
> "opened up" from compiled-in "technologies" to a
> directory-structured format more accessible to
> external tools? If I ever succeed in making my own
> analog primitive library, I'd like it to be boot-
> loaded (under .cadrc direction?) and accessible as
> any other technology. I saw some mention that there
> was now support for multiple libraries, but don't know
> if this is elaborated in the new release docs (as yet
> not unpacked).

The way to handle external tools is through disk files.  Build a facility 
in Electric that reads such a file and provides services based on the 
contents of that file.  The support for multiple libraries in the current 
release is merely a way to divide a circuit among more than 1 library file 
when it is stored on disk.

> The analog schematics "technology" has devices that
> "ask for" some attributes (like BJT area, I think)
> and/or SPICE netlist lines. I tried to "Convert and
> Edit Technology" on that technology, but it didn't
> work the same as for the process ones. Could the
> schematic technologies be broken out into editable,
> re-integratable form to allow easier generation of
> user schematic libraries?

This is a big task, and not one that will likely happen soon (unless you do 
it).  The problem is that the Schematic technology has many parameterized 
components (busses, logic gates, etc.) and these parameters are not 
understood by the technology editor.  One solution is to get this or some 
other technology to read a disk-file description of additional components 
(the fpga technology works this way).

> In the case that parameter based icon->netlisting
> capability is not realizable, I would be needing to
> make very large libraries of geometry-specific
> device symbols. The technology palette window seems
> to be constrained in number of cells, area. Is there
> a means of adding, say, component hierarchical pulldown
> menus for "New Facet Instance"?

The pulldown menus are all programmable (and so are the component menu 
entries).  Look at the "Spice" component menu entry in the Analog 
Schematics technology: it has a popup menu (new in 6.02).  To program these 
entries, you need to use Electric's low-level command language (documented 
in the internals manual).

    -Steve Rubin