[eispice] Re: General Questions.

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: