[Top][All Lists]
[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