[eispice] Re: General Questions.
- From: Charles Eidsness <charles@xxxxxxxxxxxxxxxxxxxxx>
- To: eispice@xxxxxxxxxxxxx
- Date: Sat, 18 Nov 2006 11:53:31 -0500
Hi Cyril,
Thanks for the feedback. It's great to see some interest in this
project. You have some interesting ideas and have asked some great
questions. I've responded to your questions and comments below (with a
little snipping for brevity):
Cyril Giraudon wrote:
> Hi,
>
> I like the idea I can simulate electrical circuits from a python shell.
> I think you start a very useful job.
>
> I work on scientific platforms for electromagnetism simulation and
> python becomes my preferred language.
> I have also began two wrappers around gnucap / ngspice with pyrex, but
> by lack of time, those projects sleep :-( ....
>
For a gnucap Python wrapper Thomas' work may be of interest. You can
check it out here:
http://www.desy.de/~traber/gnucap-scripts.html
> I'd like to ask some questions about eispice :
>
> 1 -
> Have you ever think of writing eispice entirely in python ? It could
> seem ridiculous, but ...
>
It's not that ridiculous but for for my purposes I don't think it makes
sense. Originally I had written eispice 100% in C (versions < 0.5) but
got tired of spending time working on the scripting language so switched
to Python for the front-end stuff. I chose the C / Python partition
based on my speed requirements. My eventual use for eispice is as a
pre-routing SI simulator for high-speed digital designs. This will
entail running hundreds of sims on every net in a design (thousands of
nets per design). Speed is very important to me and as a result I want
to keep all of the number crunching as pure C code, this includes the
processing loop, the basic device models, the numerical integration, the
interpolation, the matrix math, etc...
<snip>
</snip>
> The consequences are :
> - development easier (scripting language);
> - No compiled code;
> - Cross platform;
> - All devices models are written in python;
> - no plug-in mechanism (only a good interface);
> - Add a models on the fly;
> - Perfect integration with python shells, development environments;
> ...
>
You're definitely right, but with some work on the B element (adding
time support and direct access to python variables) it should be
possible to create any device model using a combination of B, L, and C
elements using Python based subckts (see the eisubckt.py file in the src
directory for an example subckt) which won't require any C coding. The
only time C code would have to be touched would be if a speed
improvement is desired (i.e. porting a Python based device model to C).
I think that would address most of your points, except being
cross-platform. For now eispice will only run in a posix environment
because of a small chunk of code in the SuperLU library, but it should
be possible to change that requirement some day.
> You probably know already a lot of what i've just said, but what are
> your motivations for using C language ?
> Does Eispice must be very fast, flexible, modular ?
>
See above, I think with a clean division of Python / C code it should be
possible to be fast, flexible, and modular.
<snip>
</snip>
> Do you really think Eispice must provide graphics capabilities ?
> I have already discussed this point with al davis, gnucap developer,
> (http://archives.seul.org/geda/dev/May-2006/msg00011.html).
>
Yes, I want eispice to provide basic plotting functions (nothing more
complicated than is there right now though) using "standard" Python
libraries. I tried using matplotlib but it wouldn't compile under cygwin
so I wrote my own simple plotter. For my purposes I will eventually be
plotting to files using something like PyX, but for debugging it's very
handy to have a simple fast plot function with few dependencies. There's
no reason why someone can't use the plotter of their choice instead.
> I think, the circuit simulator itself, must do the minimum amount of the
> task, furthermore in a python environment.
>
I absolutely agree, any post-processing capabilities (like plotting,
etc...) are things that I've developed for my own use and have provided
as a convenience. If there gets to be too many I may split them off into
a seperate module, i.e. eiaddons or something like that.
> When the example demands a d.tran(0.1*nano, 100*nano), are you sure
> Eispice must control the step of returned values ?
>
The step value is just a suggestion, like all spice-like simulators
eispice adjusts the step value as it goes depending on the results of
the numerical integration (to minimize cumulative error), and at any
break-points (rapid changes in slope). It uses the tstep value to derive
minimum and maximum step size guidelines. For instance, the maximum step
size is either (tstop/50) or tstep, or tmax, whichever is the least, the
minimum step size is tstep x 1e-9, the minimum time between break-points
is tstep x 5e-5, and the initial step size is tstep/100 or tmax/100,
whichever is less. Calling it tstep is a little confusing, but I wanted
to keep the nomenclature the same as in spice 3 (the equations listed
above are all from spice3 as well). I should probably add more detail to
the User's Manual.
<snip>
</snip>
> Imagine Eispice knows only simulate a [start, end] transient analysis
> and return the last calculated value (it doesn't stock result in
> memory). The python user would write the following code snippet :
>
It is possible to put the transient simulation loop in Python, but it
would be a little be a little bit more complicated than that, since the
step size is not constant for instance. Take a look at the
simulatorRunTransient function in the file "simulator.c" in the
clibs/simulator/core directory. There would be other complications, for
instance the t-line model makes use of the stored history, but if that's
being held in Python it would need to store a second local copy. I'm
just not sure if it's worth the effort and performance costs. I don't
think that the user will want to change the core simulation loop that
often.
<snip>
</snip>
> The questions are :
> What does the core of the simulator have to perform ?
>
The best place to look is the simulatorRunTransient listed above. The
algorithm is loosely based on the spice3 tran algorithm.
> How the user can interact with a running simulation ?
>
It may be possible to add a Python call-back element, i.e. like a B
element but as a Python function that returns a value instead of a B
element equation. I'll have to give that some thought but I think that
would be very cool, something like this:
def some_function(data):
return data['v(1)']*50 + sin(data['i(vi)'])
d.Bx = B('vo', 'vx', 'i', some_function)
Where the simulator calls the function at every step to get a value for
the current. I'll see if I can implement that before the next release.
It would be slow as maple-syrup in January but I think it's a safe
assumption that if you use a B element you have to expect it to be slow
regardless.
> How implement circuit linked elements (linked sources)?
>
That's possible now with a B element, but will also be possible with the
element described above. I've also been thinking about adding a digital
signalling layer to augment the analog nodes, to control devices like
drivers and receivers for static timing analysis, but that's a long term
goal.
I had a bunch of linear dependent sources in the older C only versions
but dumped them when I transitioned to Python because the B element can
do everything that they could do.
> External module : wave form creation, Eispice would accept only
> discretized curves (array) ... ?
>
esipice can use any arbitrary waveform as input using the pwl / pwc
elements (which takes a 2 dimensional array). You can generate that
array any way you'd like.
> I wish I ask useful questions.
>
You questions are very helpful, it's great to get some brain-storming
discussion. Please follow-up if you have any additional questions or
comments.
Cheers,
Charles
------------------------------------------------------------------
To unsubscribe from the eispice list send an email to:
eispice-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
Other related posts:
