[Ktechlab-devel] simulator

Celelibi celelibi at gmail.com
Sun Nov 9 15:43:15 UTC 2008


2008/11/9 P Zoltan <zoltan.padrah at gmail.com>

> On Sat, 08 Nov 2008 19:25:41 +0100, Alan Grimes <agrimes at speakeasy.net>
> wrote:
>
> > That doesn't apply because in our use case, what we are trying to
> > encode, as data are programs, which necessarily need to be interpreted,
> > no shame in that.
> >
> > It is absolutely necessary that the user be able to design components.
> > So compiled C++ is out of the question.
> >
>
>   That's clear.
>
>  But I still don't understand why do we need _programs_ describing new
> components? Where and when should those program run? (I don't really know
> the internal workings of the simulator) Wouldn't be enough to describe the
> equations of the part?
>

There will always be the one new component you can't describe without new
formulas or new algorithm.
Globally, every analogue component is composed of several pins and some
formulas that link current and voltage of every pin.

Andn you know, linear algebra theory says the vector space of functions has
infinite dimention. That means it's not possible to have a list of every
possible model of function.
That's why I suggest to keep them outside of the simulator's core.
I think an advanced user (understand, C/C++ coder) should be able to add his
own computation formulas to the simulator.

About digital circuits:
As a circuit become complex, it's execution time grows. Designing a whole
processor with only logical gates will lead to a huge execution time.
Being able to write some components in C/VHDL/whatever, really help.

I'm speaking about digital circuits, but it must be the same for analogue
circuit.
For example when your component is a specialization of another which is a
composition of two specialized components. You may really save computation
time by rewriting formulas for this component.


>> I'm not against the use of XML, but I think that only simple components
> >> should be written in XML. Others may be written in C/C++, compiled as
> >> .so and loaded at launch time (or later...).
> >
>
>   What about different CPU architectures? And 32bit vs 64bit? Plus see user
> created component argument earlier. I consider binarty, compiled component
> a bad idea, because: they would need to be recompiled for each platform
> and because a 'normal' user won't have a c++ compiler installed on his
> system.
>

You're right. That's why I refactored (?) my idea to put only computation in
.so.
I think adding components should be the last and easiest thing to do, but
everything should be ready for that.


Celelibi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20081109/990e5678/attachment.html>


More information about the Ktechlab-devel mailing list