[Xcircuit-dev] Answers to questions (!)

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

Dear Klaus,

> But i never heard something again....

Not a lost email.  I *am* still working on the XCircuit-to-PCB toolchain,
but as usual the real reason I didn't send another message was that I got
buried in email (mostly from my Homeowners' Association) and forgot about
it.  Sometimes I need occasional reminders.  :)

Most of what you want to do can be done in xcircuit already, but it will
require some writing of Python scripts.  One thing I did in response to
your questions (and others') was to spend a couple of days writing up a
lot of information about the XCircuit Python interface and posting it
to the XCircuit website.  I'm hoping someone will pick up on this and
help with the script writing, which I don't have much time to do myself.
Otherwise, I would have moved all the netlist output functions to Python
by now.  Well, no, that's not really true;  I have been working on a
couple of concepts for XCircuit (especially for use with PCB) that
require working on the C source code.  One of them is to parameterize
properties other than string values (mostly done).  The other is to
allow pin label strings to be parameterized (currently the effect of
doing that is unpredictable).  This will allow a simple way to define
"quad parts", such as 1 of 4 NAND gates in a 7400 chip.  One NAND gate
object would have 4 instances, each with its own pin numbers.

This doesn't really address your questions, but these methods have to
be coded and working if xcircuit is going to be considered seriously
for a schematic-to-PCB toolchain.

> First i think it is the easiest way to give an aditional output. there
> is spice, pcb and so on, make here an new output "to filter". I have no
> good name today :-). The output to filter should be something like the
> replaced language from part library.

The current implementation is to run the command "netlist()" from the
Python prompt.  This dumps a "generic" form of the netlist in a big,
ugly Python dictionary variable.  Python can then work through the
generic netlist and create whatever output is required.  New output
formats only require a new Python script based on one of the existing
scripts, and doesn't require modifying the XCircuit source (less work
for me!).

Personally, I prefer that all the "filters" be written as Python modules.
If done properly, they could be written such that they can run either as
part of xcircuit (as I intended) or as a true standalone filter (as you
intended).

> BTW: Can you organise it to replace all the libraries with different
> implementaions of same parts (D, R, C) with one more complete library?
> It should not be so confusing .... Let analoglib2 as a startpoint of
> improvement and remove analog at all for example.

It "evolved" to the organization it has now.  The changes I mentioned
are going to require more reorganization.  I already have a new version
of "analoglib2" with xcircuit version 2.5.0.  I agree that the
original symbols should probably be considered "obsolete" and removed
at some point.  For now, I will consider at least to move duplicated
parts into a library file separate from the unique objects, so it is
easy to remove them from the startup script.

> To make xcircuit and pcb a complete toolchain there must be a better
> input for pcb, but that's not your part, but i think it will be a
> good idea that you talk with the pcb developers to make more than a
> netlist input from xcircuit to pcb.

Well, actually, I have done some hacking on PCB, so there's no reason
why it shouldn't be "my part".

						Regards,
						Tim