Re: [Simulavr-devel] SimulAVR + simulated hardware

[Klaus Rudolph]

Hi all, 

 
> [...] I'd like to start with simulating a few LEDs and switches.

As I told to this list a few month ago I rewrote the simulavr in C++.
This simulavr version is able to simulate any number of cores with
interconnected
pins and with external hardware. Currently I added a simple TCL Script
which give
me some buttons to switch between the states (Low, pull-down, Tristate,
Pull Up and High)
and give me the responce of the calculated logic value.

"My" simulator has an time event list (a c++ map<time to next step,
avrCore>)
which enable the scheduler to give each simulated device an extra clock
freqency and
let the external hardware interact with synchron IO behaviour. The
device return the time to next
simulation step, so it is possible to simulate active clock switching
inside the device (megas are able to
switch the internal clock)
There is no Problem to "plug in" more external hardware. the only 
interface is the function Step must be provided which can be called
from the scheduler. All other things work over a "Pin" Class. This pins
are
handled inside each device (also in external hardware which is only a
special device).
If a Pin is connected with a "Net" all values of the Net will be
recalculated imediatly.

There is a lot of rework necceccary but that is not a problem of how. It
needs only a bit time to
make that interface easy and compact.



> 
> 
> C.)the README talks about a config file... I agree we should avoid
> writing any parsers...

I´m enabled my version of simulavr with the www.swig.org
interface generator to be handled in tcl. There is no problem to enable 
python or some other scripting languages as well. The complete simulator
is compiled as shared lib and can be loaded in the interpreter (wish,
python....)
and all needed actions can be configured in the script. There is no need
to write
an own parser. this is allready be done in the scipting languages at all
:-)

Example code:
load ./simulavr.so

set trace_on 1 ; # all assembler steps will be traced -> "pwm4.o"
0x234:l1_port_init+0x10 PUSH R17 IRAM[0x107f]=0x02 SP=0x10f6

set dev1 [new_AvrDevice_at90s8515]
set dev2 [new_AvrDevice_atmega128]

AvrDevice_Load $dev1 "pwm4.o" ;' load elf file to device 1
AvrDevice_SetClockFreq $dev1 75 ;# time in ns for each step

set ui [new UserInterface 7777 1] ;# add user interfae at port 7777 with



# insert all devices to scheduler
SystemClock_Add $dev1
SystemClock_Add $dev2
SystemClock_Add $ui

while(1) {
        SystemClock_Step $SystemClock ; # systemClock is a global instance,
(should be a singleton)
}



-------
Thats all.
The endless loop could also be done in a Endless funtion inside the
scheduler so the
simulation is much faster.

The Pin/Net Interface is not handled in Tcl today. This is work for the
next days. 
I need there currently some lines of C Code:

Net clk;
Net data;
Pin extClk(Pin::TRISTATE);                      //create a pin with tristate 
value
extclk.SetUiAndNetName(ui, "clk");              //give teh pin the name and
userinterface 
ui->AddPin("clk", &extClk);                     //add the pin to the ui, so the 
ui "knows"
all pins to calculate
clk.Add(&extClk);                               //add the pin to the net. So 
the net and the
external ui is connected
clk.Add(dev1->GetPin("A1");                     //add a device port pin to the 
net

//thats all :-)
The interface is not nice today so I redesign it. There must be an
external Pin.
class ExtPin: public Pin {...
        ExtPin(UserInterface &, string Name);   //so three lines of setup code
fits in one new :-)

....
If that improvement is finished the interface will also be available
from tcl or python or what else
swig will support.

> 
> D.)the actual API of course needs to be worked out. My initial interest
> is(maybe only) in AT90S8515.

This Chip is nearly complete simulated with all interrupts, timers
uarts....


> This could be interesting since on the
> surface, there are ports A-D, but of course, the pins for ports A-D can
> be used to access built-in functionality such as UART, interrupts,
> external memory, etc.. To me this means that the same pins might
> likewise have different interfaces.

I only put the actual state to the outside world. There is no knowledge 
in my simulation how the pin is working in the moment. There is only the
actual state. 
If someone is interested to bring up a gateway to the external world I
wrote
I special 8515 which have an io port which interact direct to a
unix-named pipe.
I use that way to give a much faster interface for "printf-debugging"
inside the
avr code. It is realy the fasted way for me to find some errors :-)
without the
gdb/ddd overhead.



> It doesn't make sense to simulate
> the hardware signals involved with RS-232, it should just look like a
> byte (word maybe, given 9-bit mode?) stream, right? To address TRoths'
> concern, a sample syncronous plugin could be provided to show how I/O
> signals could be buffered to allow asynchronous interaction with the AVR
> chip. This section seems to require a document that specifies the API.
> Lots of work to be done here I think!

My idea was only to give a pin state at a definite time. Thats all. No
more requirements
at all. :-) What do you think about?
 

> Comments? Concerns? Suggestions?
> 

Thats my ideas for that which are most realized.


Bye 
        Klaus