simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Trigger external component on clock cycle


From: Klaus Rudolph
Subject: Re: [Simulavr-devel] Trigger external component on clock cycle
Date: Wed, 23 Nov 2005 21:19:06 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.6) Gecko/20040114

Hi Lars,

sorry for my late answer, I am again totally busy :-(



I want to trigger some input (port change) each thousand clock cycles or
so. I guess this must be possible, but my C++ knowledge tends towards
zero, so ...


I hope that you can derive from some simple classes like the uart which gives you an idea how to implement a class which simulates a synchronous triggered device which has external connections. Please take a look inside this class first. For detailed
questions I maybe could give a more detailed information.


If I read the examples and the source correct, I'll need to have an
object, which I connect to the systemclock with Add (or
AddAsyncMember?). Do I have to create a C++-Class which derives from
SimulationMember and recompile simulavr or can this task be done also
from a (Tcl or Python) simulation script?


You could recompile the simulator, or the library if you want the hard way :-) But you also can write your own main routine and bind against the library which makes
much more sense.

If you have a clocked device, maybe every 1000 cycles you simple use the Add member function with the given time. All async members would be accessed after each! step of any! core cycle, which consumes a lot of calculation time and is not what you would do :-)

You have to create a own c++ class derived from SimulationMember.

It is not possible to derive a class on ITCL base, which comes not from design of simulavr but of the swig wrapper. This is not really nice, but it is the price of using wrappers :-)

But you also can write a script which steps the engine "manually" and change the pin state after 1000 steps/cycles. So you need no new class and no new main nor a recompile. If this solves your problem and is fast enough you could do this in this way.

Have fun!

Klaus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]