discuss-gnu-electric
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: James Swonger
Subject: Re: Electric symbols ("icon") creation & netlisting
Date: Thu, 07 Dec 2000 14:20:29

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?

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?

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 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?

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"?

MOS
BJT     > NPN > 1C1B1E
JFET      PNP   2C1B2E > 11x16x11
DIODE           2C2B1E   11x20x11
RES             ARRAY    11x25x11
CAP                      11x32x11
                        11x40x11
                        11x50x11
                        11x64x11
                        11x80x11
                        11x100x11
                        11x160x11
                        11x200x11


because, obviously, a linear list would be excruciatingly long.
So is the translation of umptyhundred variations of already-
existing paramtric models to fixed-geometry, but that's another
issue.





It may be that this mostly involves the simulation interface tool,
perhaps getting it to look at a side file for netlisting cues
or at the icon for additional properties?

For example, in older versions of our Cadence tools, each symbol
(or cdsSpice) rep had a property called palNetlistProcedure
which indirected the netlisting, referencing startup-loaded
IL functions (as many as you wanted to borrow or write) and
dictating the format and argumenting of the netlist line(s).
Each library had its own cdsSpice.il file pulled up through
the autoload chain of events. Electric seems to have a much
more spare library structure, but maybe it's a lack of
.cadrc elaborateness? Maybe this is something that a TCL
SPICE netlister should be developed for, to layer on some
abstraction?

This can only be done with the interpretive languages, and even then it
demands a bit of extra code that Electric doesn't currently have.

The SPICE code for a facet instance can be overridden and replaced with the
contents of a disk file.  What you really need is the ability to take that
override from an attribute on the facet.  This is simple to implement, but
not there now.  Once you can use an attribute instead of a disk file, you
can make that attribute be code (LISP/TCL/Java).  Then you build code that
examines the parameters and produces the appropriate SPICE line.

The library with these code attributes would not work on a system that
doesn't have the languages installed.

     -Steven Rubin


_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]