xcircuit-dev — XCircuit news and discussion

[Xcircuit-dev] Editing Data Sheets?

[Bob P. <bpa...@cs...>]

I have a .PDF data sheet that I'd like to extract sections from and include 
them in to a XCircuit schematic, preferably with out retyping/redrawing it 
by hand.

I've tried using GhostScript to convert a page of the .PDF to .PS format.

The .PS looks really bad, at any resolution, compared to the .PDF file.

Any way is there a way to feed this in to XCircuit?  I've tried Read, nothing 
use full happens.

Import Background does do that, but you can't edit the background.

Any ideas?

[Xcircuit-dev] blobs and entities

[R. T. E. <ti...@st...>]

Dear Bob,

> Actually a double indexed normal array might work.
>	"part[entity][blob]={x/y,pins}"
> kind of thing.  You can now rename/renumber the entities
> because they are independent of the blob/pin info.

That makes sense.  I think the way to handle that is to
expand on the "infolabel" so that an object can be
declared to belong to a specific entity without assigning
it a part number.  It would probably be a good idea to
start standardizing the methods used by the "infolabel",
as this is where all the bookkeeping happens.  But the
general idea is that you would have

	"pcb:U<param1>-<param2>"

which declares actual part numbers, but also

	"pcb:entity[<param3>]"

which declares the object as belonging to a particular
chip, or entity.  If <param1> is changed in this
object, it will be similarly changed in all objects
having the same <param3>.  When you grab one "quad
part" component from the library, you will get all
four transferred to the page, and all of them
automatically assigned the same <param3>.  More
bookkeeping can be dealt with by

	"pcb:parts[DIP7400-1,DIP7400-2,DIP7400-3,DIP7400-4]"
	"pcb:pin[7]=GND"
	"pcb:pin[14]=Vdd"

The first one declares that there are four parts to
the entity, so that any missing parts can be added
to the PCB netlist output as unconnected entities.
The parts are listed by name, so that they don't have
to be the same, as in your relay example.  Because
my "libinst" parts all have the same name, I have to
think more about how the "-1", "-2", etc., should be
specified both in the infolabel and in the library part
name.  The last two deal with the Vdd and GND pins, or
any other pins not belonging to any of the parts
themselves.  The netlist generator would know to
generate a netlist entry for only one of these per
entity.

I'm making up syntax as I go along, which is why I
say I should be "standardizing the methods".  But
regardless, do these ideas seem to you like a good
way of implementing multi-part entities?  Any ideas
you have on syntax?  Standards would probably
require something like:

	"pcb1:entityname=U"
	"pcb2:entityparts[DIP7400-1,DIP7400-2,DIP7400-3,DIP7400-4]"
	"pcb3:entity=<param3>"
	"pcb4:part=<param1>"
	"pcb5:subpart=<param2>"
	"pcb6:pin[7]=GND"
	"pcb7:pin[14]=Vdd"

Warnings will pop up if you do something inconsistent, like a
duplicated part or subpart.  Otherwise you would be free to
show unused parts on the schematic, or not, as you please,
and you're free to (re)number the part or let auto-numbering
do its thing.

Since this involves standards and opinions, I'll CC this email
to the xcircuit-dev mailing list so anybody listening in can
weigh in on the issue.

					Regards,
					Tim

[Xcircuit-dev] help please!

[Narciso M. <nar...@us...>]

Hi,
I've tried Xcircuit 2.2.0 for windows in windows 95 with xwinpro and
xwin32 and it works perfectly. It's a great package.

But I have windows 98 at the University, and I found that it reports an
error message like this: "RXVT causes a page fault in module
KERNEL32.DLL". I have this message with both Xservers.

Otherwise, I wanted to try the other option under VNC. I've installed
that, but I don't know how to work with XCircuit under VNC.

I would be gratefull if you could help me, because I haven't found a
program which produces a high quality ps circuit like that.

Thank you in advance.
Narciso Moreno.
-- 
Narciso Moreno Alfonso
Dpto. Ingenieria Electrica
Escuela Universitaria Politecnica
c/Virgen de Africa, 7
41011 Sevilla (Spain)

Tel.: +34 95 455 6980
Fax.: +34 95 428 2777
E-mail: nar...@us...
-------------------------------------------
	Trabaja como si no necesitases el dinero.
Ama como si nunca hubieses sido herido.
	Baila como si nadie te observase.
Canta como si nadie estuviese escuchando.
	Vive como si el Cielo fuera la Tierra.

[Xcircuit-dev] Another fix

[R. T. E. <ti...@st...>]

Dear Bryce,

   A colleague of mine found another fallout of the change in the way
xcircuit does netlists;  editing pin labels does not force an update
of the netlist.  The fix for this is that elements.c, line 393, should
be changed from

      else eventmode = NORMAL_MODE;

to:

      else {    /* (hasstuff && eventmode != CATTEXT_MODE) */
         eventmode = NORMAL_MODE;
         incr_changes(objectdata);
#ifdef SCHEMA
         if (curlabel->pin != False) objectdata->valid = False;
#endif
      }


						Regards,
						Tim

[Xcircuit-dev] XCircuit feature request

[R. T. E. <ti...@st...>]

Dear Rob,

> My intention is to create electronic block diagrams. An excellent
> editability of drawings is desired. For me this means, that moving or
> resizing a block in the drawing (representing a distinct functionality)
> will automatically adjust the connecting wires connected to it (without
> losing the connections to other blocks!).
> Say, something like the smart link option in xfig. Nevertheless, xfig is
> no alternative, partially due to bad keyboard utilization for commands.

> I did not find a capability to arrange smart moves [in xcircuit].

Behavior prior to version 2.5.3 was to generate a netlist for every
netlist-related command and destroy it afterward.  This made it impossible
to do "smart moves".  As version 2.5.3 has only been around for a few
weeks, I have not had time to think about adding new features.  However,
it does retain the netlist at all times, which makes it possible now to
add the "smart move" feature.  It has been requested several times
before, so it will be a high priority.

						Regards,
						Tim

[Xcircuit-dev] Re: pcb library

[R. T. E. <ti...@st...>]

Dear Bryce,
   Contact Harry Eaton (hac...@ap...) and ask for the latest
version of PCB (1.99, or something like that) which (according to Harry)
has some extra features for making libraries, and has extended the library
format to include more layers than just pins and silkscreen.  I was supposed
to be beta-testing this version, but I've had too many other things to do
recently.
						Regards,
						Tim

[Xcircuit-dev] revised answer

[R. T. E. <ti...@st...>]

I take back my last answer.  There was a temporary label created by the netlist
generator which should not have been selected in the first place;  I put the
code in to ignore such labels in the "select object" code but not in the "select
area" code, which is why xcircuit crashes when you draw a select box but not
if you click on the object to select it.  The correct solution should be the
following lines added to selection.c, line 659:

#ifdef SCHEMA
           /* Ignore temporary labels created by the netlist generator */
           if (slab->string->type != FONT_NAME) break;
#endif

This will prevent other crashes that would arise from the same condition
but would not have been covered by the previous bug fix.

						Regards,
						Tim

[Xcircuit-dev] autonumber causes a crash?

[R. T. E. <ti...@st...>]

Dear Bryce,
   The crash is related to creating the netlist, not the autonumbering
function.  It comes from changes I made which cause the circuit netlist
to be retained so that xcircuit doesn't waste time re-creating the
netlist over and over again.  There were some loose ends on that code,
though.  Thanks for the detailed bug report.  The fix is to change
"selection.c", line 193 from

	 setfontmarks(mlabel->string->data.font, mlabel->justify);

to:

	 if (mlabel->string->type == FONT_NAME)
	    setfontmarks(mlabel->string->data.font, mlabel->justify);

I will make the change to the distribution as soon as I have worked
through the rest of the bug reports I received over the past two weeks.
I was in China from Feb. 9 to 23, so I have collected quite a bit of
email.
						Regards,
						Tim

[Xcircuit-dev] Loading Pyton modules at start up?

[Bob P. <bpa...@cs...>]

I know I must be over looking some thing that is staring me in the face,
but after poking around the docs and source for the last hour I can't find
it.

How do I get the python modules like 'pagebox.py' to be loaded when
I startup XCircuit automatically?  Doing F)ile/Execute Script each time is 
getting old...

[Xcircuit-dev] What shoud 'test.py' do?

[Bob P. <bpa...@cs...>]

I'm running Mandrake 8.1, I tried running test.py, but I'm thinking
I don't have some thing installed right.

When I execute the script 'test.py' I get this:

Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError
Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError
Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError

[Xcircuit-dev] panzooming in the libraries?

[Bob P. <bpa...@cs...>]

I think the 'panzoom.py' feature is a good one that I would
like to use by default.

Alas it seems that it only works at the schematic level.
Zoom In/Zoom Out stops working at all at the library level, 'L'. :-(

[Xcircuit-dev] What shoud 'test.py' do?

[Bob P. <bpa...@cs...>]

I'm running Mandrake 8.1, I tried running test.py, but I'm thinking
I don't have some thing installed right.

When I execute the script 'test.py' I get this:

Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError
Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError
Traceback (most recent call last):
  File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ?
    from math import pi,sin,cos
ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: 
PyExc_OverflowError

[Xcircuit-dev] Loading Pyton modules at start up?

[Bob P. <bpa...@cs...>]

I know I must be over looking some thing that is staring me in the face,
but after poking around the docs and source for the last hour I can't find
it.

How do I get the python modules like 'pagebox.py' to be loaded when
I startup XCircuit automatically?  Doing F)ile/Execute Script each time is 
getting old...

Re: [Xcircuit-dev] pcb library

[Bob P. <bpa...@cs...>]

On Friday 15 February 2002 02:14 pm, Bryce Denney wrote:
> I'm getting ready to make an xcircuit library of common pcb parts, and the
> first on my list is headers: 1x2, 1x4, 1x6, 2x2, etc.  The only question
> is what pin numbering scheme to use for dual row headers.  Is there any
> kind of standard for this?  Does anybody have a preference?

> c)
> 02 04 06 08 10 12 14 16
> 01 03 05 07 09 11 13 15

Is the one I run into the most often.

Usual it is up to the manufature, and how the did
the data sheet.

Also it maters if your talking about the top mounting or the
bottom mounting on the board.

> IMHO, c and d make sense if you're using IDC connectors to ribbon cable,
> but otherwise a&b are more intuitive.  No, I don't want to make one for
> every possible combination. :)

Thats to bad.. ;-)

> I'll also be making a matching layout symbol for all these parts, using
> pcb for linux.  I haven't figured out how to make a library in pcb,
> yet.

Take a look here:
http://russ.dhs.org/pcb_logo.html

> Please let me know if anyone else is working on this, or is interested in
> working on it with me.

I'm always happen to share the parts I make.  Tim has already posted the ones 
I've made on the XCircuit Home Page.

[Xcircuit-dev] 74xx DIP library

[Bryce D. <br...@tl...>]

I just posted xcircuit libraries for all 74xx series chips on Source
Forge.  They're generated by a perl script so they're not all beautiful,
but it sure beats typing them in.  The info is based on a library from
from the sources of pcb for linux.

https://sourceforge.net/tracker/index.php?func=detail&aid=518207&group_id=4952&atid=304952

Bryce

Re: [Xcircuit-dev] pcb library

[Bryce D. <br...@tl...>]

Here's the first draft of the header library.  The library turned out so
small that I'm attaching it to this message.  These are intended to be
schematic symbols that represent PCB parts.  The attached file is
pcb-headers.lps.gz.  The headers look like this:

     J?
   +---+
 --| 1 |
 --| 2 |
 --| 3 |
 --| 4 |
   +---+

I put visible pins sticking out on the left so that you know which side
the pins are on.  If you flip it, they will stick out on the right of
course.  The instance name (J3, etc.) appears on top of each one, and
there's an info pin for "pcb:J?".  The dual row headers are labeled in
style 'A', as described in my previous message.

This library includes headers of these dimensions:
1x2, 1x3, 1x4, 1x6, 1x8, 1x10, 1x12, 1x16
2x2, 2x3, 2x4, 2x6, 2x8, 2x10, 2x12, 2x16

Let me know if you find any problems.

Bryce




On Fri, 15 Feb 2002, Bryce Denney wrote:
> I'm getting ready to make an xcircuit library of common pcb parts, and the
> first on my list is headers: 1x2, 1x4, 1x6, 2x2, etc.  The only question
> is what pin numbering scheme to use for dual row headers.  Is there any
> kind of standard for this?  Does anybody have a preference?
> 
> a)
> 09 10 11 12 13 14 15 16
> 01 02 03 04 05 06 07 08
> 
> b)
> 01 02 03 04 05 06 07 08
> 09 10 11 12 13 14 15 16
> 
> c)
> 02 04 06 08 10 12 14 16
> 01 03 05 07 09 11 13 15
> 
> d)
> 01 03 05 07 09 11 13 15
> 02 04 06 08 10 12 14 16
> 
> IMHO, c and d make sense if you're using IDC connectors to ribbon cable,
> but otherwise a&b are more intuitive.  No, I don't want to make one for
> every possible combination. :)
> 
> I'll also be making a matching layout symbol for all these parts, using
> pcb for linux.  I haven't figured out how to make a library in pcb,
> yet.
> 
> Please let me know if anyone else is working on this, or is interested in
> working on it with me.
> 
> Regards,
> Bryce
> 
> 
> _______________________________________________
> Xcircuit-dev mailing list
> Xci...@li...
> https://lists.sourceforge.net/lists/listinfo/xcircuit-dev
> 

[Xcircuit-dev] pcb library

[Bryce D. <br...@tl...>]

I'm getting ready to make an xcircuit library of common pcb parts, and the
first on my list is headers: 1x2, 1x4, 1x6, 2x2, etc.  The only question
is what pin numbering scheme to use for dual row headers.  Is there any
kind of standard for this?  Does anybody have a preference?

a)
09 10 11 12 13 14 15 16
01 02 03 04 05 06 07 08

b)
01 02 03 04 05 06 07 08
09 10 11 12 13 14 15 16

c)
02 04 06 08 10 12 14 16
01 03 05 07 09 11 13 15

d)
01 03 05 07 09 11 13 15
02 04 06 08 10 12 14 16

IMHO, c and d make sense if you're using IDC connectors to ribbon cable,
but otherwise a&b are more intuitive.  No, I don't want to make one for
every possible combination. :)

I'll also be making a matching layout symbol for all these parts, using
pcb for linux.  I haven't figured out how to make a library in pcb,
yet.

Please let me know if anyone else is working on this, or is interested in
working on it with me.

Regards,
Bryce

[Xcircuit-dev] Xcircuit for Mac OS X

[Marcelo H. R. <mar...@sp...>]

Hello!
Does exist a version of xciruit for Mac OS X? Where can I download it?
Thank you!

Marcelo Hern=E1n Ruiz
mar...@sp...
cha...@ho...
ICQ 47712987
Visit=E1 www.webabierta.com=20

[Xcircuit-dev] autonumber causes a crash?

[Bryce D. <br...@tl...>]

I was playing with xcircuit 2.3.5 using redhat linux 6.2, and I found
that it will sometimes segfault soon after autonumber components.

start xcircuit 2.5.3 with no diagram
press L to see the libraries
click into generic
click diode
place the diode in the diagram
select Netlist:Autonumber components
use the middle button to drag a box around the gate to select it.
segmentation fault

It's not specific to diode--it happens on every gate I've tried. But if
you select it by clicking the middle button it's ok. I'll get you a 
stack trace if you have any trouble reproducing this.

Thanks,
Bryce

[Xcircuit-dev] Diagram Request

[Maharaj, S. (Sandhaya) <San...@ne...>]

Can u please forward a schematic circuit diagram for CS 6229 Z Samsung 64cm
TV.  Please forward to Ste...@ne...

Sandhaya Maharaj 
Tel: {011} 295-5585
Fax: {011} 294-5585
san...@ne...

[Xcircuit-dev] SPICE and XCircuit

[R. T. E. <ti...@st...>]

Dear Nik,
   There was one attempt to write a SPICE-to-xcircuit converter, by
Jayant Jere. . . see http://xcircuit.ece.jhu.edu/contrib/contrib.html.
However, I've never seen this program.  If I have some extra time, I'll
try to write one, because I think it's a very useful application.

   I'm not familiar with IBIS.  Can you point me to any online
documentation about the format?

						Regards,
						Tim

[Xcircuit-dev] Tim, did you get a new email address?

[Bob P. <bpa...@cs...>]

>    As I have mentioned to others, but I don't know if it's widely known,
> starting next week I will be working Thursdays and Fridays from home,
> doing exclusively EDA programming and development related to ScriptEDA.

Tim, did you get a new email address?  All email to "R. Timothy Edwards" 
<ti...@st...> is being returned in the last couple of days.

[Xcircuit-dev] IBIS or SPICE import?

[Nik K. <nk...@ma...>]

Hello!
Is it possible to import files in IBIS or SPICE format to XCircuit?
Is there any GPL projects which support IBIS or SPICE formats?
    With repsect Nik.

[Xcircuit-dev] Dev contributions

[John H. <ed...@sc...>]

Hi,

How do I contribute code and libraries ?
I seems soureceforge is behind the web page.

Thanx much

John H.

[Xcircuit-dev] The "scriptEDA manifesto"

[R. T. E. <ti...@st...>]

Hello everyone,

   I've had the opportunity recently to play around a bit with the idea of
"scriptEDA", which is one of those ideas which is amazingly simple provided
that the resources exist to make it happen.  In this case, the person to
recognize that the resources are in place to make possible the integration
of many or all of our disparate open-source EDA tools is Pinhong Chen at
UC Berkeley.  If you have not heard of "scriptEDA", I urge you to visit
his website at http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/, and
read the several papers you can download from there.

   The following text is some thoughts I had on an implementation of
scriptEDA which would include the major open-source EDA tools that I know
of and/or am involved in the development of.  Please keep in mind that
this is just a collection of first impressions, and the main thing I would
like to get out of it, at the moment, is feedback and opinions.  I would
like to see the open-source EDA movement become an integrated system to
rival the big EDA companies like Cadence and Mentor Graphics; but it should
be the Bazaar, not the Cathedral, as Eric Raymond would say, as befits the
open-source software movement in general.  I think the scriptEDA idea may
be the right path to take to get there.

						Tim Edwards
						January 15, 2002

The scriptEDA "manifesto" v0.1
---------------------------------------

"ScriptEDA" is a general-purpose method for integrating various CAD
tools, envisioned by Pinhong Chen, U.C. Berkeley.  The idea is that
many EDA tools have their own command-line interfaces, often very
spare, usually with a unique syntax, and rarely offering capability 
beyond executing internal commands and changing the application's
internal state.  If all of these programs can be "wrapped" by an
interface to a well-known interpretive scripting language, then they
can have both a consistent interface, and a method for sharing data
with other EDA programs.  The interface generator known as "SWIG" is
capable of generating wrappers for the major scripting languages,
including Tcl, Perl, and Python  (I have played around with SWIG,
and I have found that the "stable" version 1.1p5 chokes up on
X11-based programs, but that the development version 1.3.10 breezed
through the entire source of XCircuit, generating a 1MB+ source file
which compiled (eventually, after I climbed the learning curve) without
a hitch).

Visit the SWIG website (www.swig.org) for details on the implementation
of SWIG, but in a nutshell, what SWIG does is to take a standalone
program and a ".i" file which describes which routines should be
accessible when called from an interpretive scripting language, and
writes the bits of C code necessary to interface between the syntax
of the scripting language and the indicated program subroutines.  The
program's main() routine is ignored, and the rest of the program
becomes a shared object (.so) library file, a module for a scripting
language like Tcl, Perl, or Python.  Instead of being run from a
shell, the program is run from the scripting language interpreter.
This does not slow the program down in any way, as the only change
from the program's standpoint is that its entry point has changed.
There is some impact on memory usage, as the interpreter itself takes
memory, and so does the wrapper code.  However, these are what I
consider to be necessary tradeoffs for suddenly having an easy way
to integrate all programs which run under the same interpreter.
The interpreter has direct access to the internal data structures
of the program through the selected subroutines made visible to it.
This makes the program extendible through scripts, and provides a
simple way for programs to share data with one another.  It also
provides a way for users to access low-level functions in a program
without messing with the source code.  And finally, it allows users
to create extensions to a tool in whichever scripting language they
like best, so they don't have to stumble along, trying to learn
the vagaries of the syntax of the scripting language that happens
to be the favorite of the tool's developer (like Python for me, or
Scheme for Rajit. . .).  Although some of the resulting code will
probably run much slower than a user would want it to, it's much
easier and more practical to start with a working script, then
code the equivalent directly into the source to make it run fast,
than it is to try to code that function directly into the source
to begin with (particularly if the script communicates between
two different tools).

Insofar as many EDA programs are command-line driven, the wrapping
method is quite simple.  However, a number of critical EDA programs
are GUI-driven, and may or may not have a command-line interface in
addition to menu functions and direct GUI input (mouse or keyboard;
e.g., X11 events).

What I would like to have is a document concerning the implementation
of all EDA programs, including those without existing command-line
interfaces, under a "scriptEDA"-type environment.  It need consider
only open-source programs, that is, those which can be readily modified
to fit into the scriptEDA system.  Of major significance will be:

	Magic (VLSI layout),
	PCB (printed circuit board layout),
	SPICE (analog simulation),
	rsim (digital simulation),
	gemini (LVS),
	xcircuit (schematic capture), and the various components of
	gEDA (gschem, acs, etc.).

What's written below is not specific enough to be considered an API.  It
is more of a overview of the things that an API is going to need to consider
in detail.

The overall intention is to create a system with the following properties:

1) Every component of the system can be run independently (that is, without
   being launched from within the scripting environment), or as part of
   scriptEDA.  At compile time, each program will generate one or more shared
   libraries of its internal subroutines.  The standalone executable will only
   define the main() routine and any routines defining a command-line interface
   which are not used under the scriptEDA system.  Preferably, the shared
   library itself should be divided into several parts, one core part used
   by the standalone version and all of the interpreters, and one shared
   library for each interpreter compiled (Tcl, Perl, Python).

2) In conjunction with part (1), at compile-time, each component will allow
   compilation for any of the interpreters which are declared as part of the
   API, as well as (optionally) compilation of the standalone program.
   Supported interpreters will probably be limited to Tcl, Perl, and Python,
   as the major interpretive scripting languages used today for EDA work.
   Because SWIG is defined independently of all interpreters, compilation
   can be done for any interpreter supported by SWIG, but the "glue" scripts
   which hold the system together will be developed and supported only for
   the major languages defined by the API.  This, of course, can be changed
   at any time, as warranted.  The reasoning behind this flexibility is that
   the long-term existance of any one interpreter cannot be guaranteed, but
   as all of them are capable of the same essential functions, translation
   of scripts between different languages is fairly easy to maintain.

3) Each component (application) is free to be developed with minimal
   constraints as to how it must act within the scriptEDA environment.
   The scriptEDA system may not force the reimplementation of a program's
   GUI or internal data organization.  However, recommendations may be
   made which suggest development directions which enable better
   compatibility with other programs in the scriptEDA system.  An
   application may cede its GUI to the interpreter if requested, but is
   not forced to do so.  The reason that this is not made a requirement
   in the API is that many applications have GUI operations so tightly
   integrated into the program that separating them out would not be
   feasible except maybe as a long-term project (e.g., xcircuit and PCB).
   The degree to which a tool is willing to cede its non-time-critical
   functions to the interpreter will likely have a direct impact on its
   success within the scriptEDA system.

4) The scriptEDA system may not *require* a particular component.  For
   example, both gschem and xcircuit are viable schematic capture
   programs;  a designer may find gschem better for digital and PCB
   design, and may find xcircuit better for analog and VLSI design.
   One tool should be able to appropriately replace the other within
   the scriptEDA system.

-----------------------------------------------------------------------
Operation

The "top level" of scriptEDA consists of starting the interpreter.  The
interpreter, in turn, generates a thread for each application program,
and manages data transfers between all of them.  Creation of threads may
be from the interpreter command line (e.g., a call to "magic" with
arguments), or it may run a GUI as part of the master thread (e.g., a
windowed environment with file load/save dialog boxes and such, and
perhaps tabs to switch between application windows).  The application
program might relinquish all of its callback operations to the controlling
GUI if requested.  The application will want to keep time-critical
operations to itself.  It will be necessary to have a naming convention
for calling tools from the (each) interpreter.

Interactive programs will require some method to return to the calling
interpreter.  Running each application as a separate thread gives a bit
more flexibility in choosing the communication method between the
interpreter and the applications.  Programs may communicate data directly.
The master thread may make calls to query the internal data structure of
any program at any time.  This means that every application program will
need to acquire and release mutex locks when altering data which may be
visible to another thread.  Another method would be to have each
application program accept a particular signal (interrupt or event such
as an X11 event) which will cause it to suspend execution until receiving
another signal, during which time another thread could access its data.

An example of this is provided by a recent demonstration of ng-spice
inside an interpreter environment.  Rather than run SPICE as a "batch
job" and require ".print" statements on all nodes to be queried at
run-time, generating huge output files, the calling interpreter
simultaneously runs ng-spice and a graphics plotting program.  There
are several possibilities here.  SPICE can run as usual, with a ".print"
statement, but with the interpreter redirecting SPICE's stdout to itself,
reading the output, and passing it as input to the graphics plotting
program.  Alternatively, SPICE could send one value (time, most likely,
or just a boolean value handshaking flag) and stall while the interpreter
reads its data structures directly and passes the information to the
plotting program.  If speed is of the essence, then a third possibility
assumes that the plotting program is written specifically to parse SPICE
output, and the interpreter is then responsible for linking the output
of SPICE to the input of the plotting program via a pipe, and interrupting
SPICE whenever a change is needed in the simulation parameters.

To take this one step further, we imagine an example in which we launch
four application programs:  magic, for VLSI layout; SPICE, for simulation;
the plotting program, for visualizing the simulation output; and ext2spice,
which generates SPICE decks from magic layout.  The controlling interpreter
is running a GUI which has a tab interface, from which we choose "magic" as
the active input window.  The GUI also has menu, which offers a selection
"simulation" with items "start", "stop", "reset", "add node", and "remove
node".  On choosing "reset", the interpreter sends an "extract all" message
to magic, and then launches "ext2spice", which generates a SPICE deck, which
is passed to the simulator as input (or, better, ext2spice can be rewritten so
that it acts as a filter function between magic and SPICE, avoiding any file
creation at all).  In magic, we select a node using the usual magic selection
mechanism.  Then we choose menu item "add node", which sends a "getnode"
command to magic, grabs the output, then sends a "print" instruction to
SPICE.  On choosing "start", SPICE begins running, and passes values for
the specified node to the plotting program for output.  Conversely, we
can activate the plotting program window, highlight one of the traces
being plotted, and execute a "go to node" function in magic which will
move to and highlight the selected node.  The voltage value of the node
at the current simulation timestep could be printed in magic as it
executes.  In a way, this functionality is similar to "irsim" in Magic,
except that components such as graphical output can be added without
altering the source code of magic, and the entire simulator can be changed
(repacing "ext2sim" with "ext2spice" and "irsim" with "SPICE", or ACS, or
analog/diglog, or whatever).  In addition, the interface is smoother
("ext2sim" or "ext2spice" run automatically, and the tech file(s) needed
by irsim or the models needed by SPICE can be determined from the internal
state (technology data structures and path specifiers) of magic) than the
existing "rsim" interface in magic.

Finally, an added bonus to this method is that the "rsim" interface can be
completely removed from magic, reducing some of its excessive `code bloat.'
The same is true for basically ANY feature of an EDA tool which is better
developed apart from the core program.  This applies (in my opinion) to
all of the following tools in magic:  The routers (all of them!), the
wire tool, irsim/rsim and the rsim tool, the netlist tool and window, and
the color window.

-----------------------------------------------------------------------
Development

Implementation of scriptEDA around programs which are inherently command-line-
interface oriented and which do not have a GUI is straightforward and follows
the recommendations outlined by Pinhong Chen.  Entire command sets are
wrapped such that they are translated directly into scripting language
equivalents.  Program output is captured from stdout where required.
Programs with more complicated interfaces probably need to be considered on
a case-by-case basis.  For each program, it will be necessary to determine
which functions need to be accessed by the interpreter, and which may be
considered "private" functions.  If SWIG is told to process every single
routine, it will generate a wrapper for every single routine, and the
resulting C code source file can be larger than the rest of the program
combined.  By choosing judiciously which functions should be accessed, the
interpreter wrapper interface can be kept reasonably small and efficient.

Magic:
Magic already has an embedded "scheme" interpreter.  Since "scheme" can be
chosen at runtime, it is easy enough to disable it when compiling for
scriptEDA.  The main problem with magic is its incredibly complicated
I/O interface, using a forked process to handle X11 calls, such that it
gets inputs from dual sources: the calling shell, and the X11 event queue.
To further complicate things, a choice of graphics interface can be compiled
in and selected at runtime, so the X11 interface may be bypassed altogether.
Probably the best thing to do with magic is to leave its X11 interface in
place and replace the interface to the terminal with a connection to the
interpreter.  So the function which normally blocks on a "select" function
waiting to get input will be rewritten for scriptEDA to simply return to
the interpreter.  The interpreter, not TxDispatch(), will call magic
functions.  In fact, the entire "textio" interface will probably be missing
from scriptEDA magic, with the TxDispatch() calls handled as specified in
Pinhong Chen's scriptEDA "Case Study".  It is probably not wise to tinker
with the XHelper7 process, namely because X11 is not thread-safe, and if
operated as a thread, it likes to rearrange X11 calls until it confuses
itself to death.  I am not sure yet how to deal with command line entry
from key events grabbed through the XHelper7 process.

XCircuit:
XCircuit is another program with an embedded interpreter but fortunately,
like Magic, it can be compiled without it.  However, "without it" means
that XCircuit runs its own pitiful scripting language.  The current
development direction for XCircuit is to get rid of the embedded
interpreter in favor of the scriptEDA extended interpreter, which would
then do a lot of file handling itself, including handling of netlist
formats and disk I/O.  Because XCircuit is inherently GUI-oriented, and
not command-line oriented, it will need to add a method to return back
to the interpreter for command execution and scripting-language file
execution.  Because the widget operations are horribly intertwined with
the rest of the code, getting XCircuit into a state where it can
relinquish control of the GUI to the interpreter, when requested, will
require a LOT of work.  Meanwhile, its major task within scriptEDA will
be for netlisting and LVS in conjunction with magic and PCB.  When LVS
is confirmed, it can receive simulation feedback in the form of voltage/
current/digital signal values printed by specified nodes as the simulation
progresses, and highlighting a node can simultaneously highlight the
equivalent node in the layout and the trace for that node in the
simulation.  If LVS is not confirmed, separate simulations can be run
on the schematic and the layout and compared.  LVS itself should provide
feedback directly into the layout and schematic programs.

Gemini:
Gemini is an LVS program.  When LVS is required, it will take input from
the layout and schematic capture programs, and attempt a match.  Because
text output from LVS is inscrutable at best, it will be preferred for
the interpreter to have direct access to the internal state of the LVS
program, from which it can extract the node name information necessary
to highlight those parts of a circuit which are believed to be matched.
Feedback can be used to resolve automorphisms (assuming anyone cares),
and selection of a node in either the layout or schematic will highlight
the equivalent node in the other.  The main reason for direct access to
data structures is that while net names can be requested and shown in
layout and schematic applications, device names (in VLSI; that is,
transistors, resistors, capacitors, etc.) are generated by the LVS
program on the fly.  Gemini documentation suggests that at least one
version of gemini knows how to write feedback layer information in the
form of a magic ".mag" file.  I have never seen this part of the code,
but it should be recovered or rewritten.

SPICE:
ng-spice has already been modified to run in a scriptEDA environment.
It is probably necessary to do some more work to give the calling
interpreter greater control over internal routines, such that
experimenting with ways to overcome convergence difficulties could
be tried as scripts.  Too much scripting control is probably not
advisable, because SPICE needs to run as fast as possible.  The nice
thing about scriptEDA is that it has the potential to SPEED UP 
simulations by bypassing all the disk accesses required by lengthy
disk operations.

PCB:
PCB would benefit from transferring all of its rats-nest and netlist
capabilities to the controlling interpreter.  This would allow easier
integration with a schematic capture program.  PCB does not have a
command-line interface, so it will need a way to return to the
calling interpreter or else allow parallel access to its data
structures using handshaking.  A command-line interface will be
more-or-less built in the interpreter, with occasional code changes
needed to support the interface and/or make it consistent and clean.

rsim/irsim:
I have not looked much at the irsim code, but since it is run
entirely by command-line interface, wrapping it into scriptEDA
should be straightforward and follow the procedure outlined in the
scriptEDA papers, with little or no modification to the source.
As mentioned above, though, it is its interface to magic, written
into the magic source, which should be removed and transferred to
the interpreter.

Mixed-mode simulation:
An interesting question is whether the scriptEDA system could actually
break up a circuit into digital and analog parts, and run each part
separately as a SPICE or irsim simulation, with each part passing its
outputs to the others at each timestep, and the interface controlling
the D/A and A/D conversions and the matchup of timesteps.  It's an
interesting possibility.  I've always been annoyed that some mixed-signal
simulations have to run excruciatingly slowly because 95% of the circuit
is simple digital gates but has to be simulated in analog along with the
5% of the circuit that's truly analog.  If done correctly with threads,
the result should run efficiently in parallel on a multi-processor system.

gEDA:
I know very little about the impelentation details of the gEDA
application programs, so I will need Ales Hvezda and others involved
to make some comments about fitting them into the scriptEDA scheme of
things.  Please feel free to add comments and suggestions for individual
gEDA tools here.

-----------------------------------------------------------------------