simulavr-devel
[Top][All Lists]
Advanced

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

[Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitte


From: ThomasK
Subject: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Date: Wed, 26 Feb 2014 06:42:58 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi list,

again a question to discuss:

Markus has proposed a new feature (see http://savannah.nongnu.org/bugs/?40594 and Markus repo with this feature on https://github.com/Traumflug/simulavr)

What does it do? In a similar way as avr signature it's possible to link into elf file some mor information about the program and how to simulate this. The idea comes from simavr: https://gitorious.org/simavr.

The information are:

- controller name (e.g. "atmega32")
- clock frequency
- serial input from file and serial output to file
- simavr holds too VCD configuration, tracefile, core voltage
- ... there are many more thing, which **could** be hold there

How is it made?

For each information a special specification structure is created (it's a simple C structure definition, for example for clock frequency a tag, that this is for clock frequency and a long value, for controller name a string and so forth) This structures are tagged for a special section ".siminfo" and linked together into elf file at a special virtual address. (but not used by program!)

My opinion: this is a smart solution to inform simulavr: for what controller th program is build, for which clock frequency it's build. So on one hand, there is (if the elf file is linked with that!) one source for mistakes in simulation removed and you haven't to give controller name and clock frequency on start of simulavr. (option -d and -F)

But I wouldn't implement the part to control for example serial io: a) it's just a simple solution, for input the character are taken from file, but without timing char by char without time control between. (ok, that isn't really a reason, it's possible - with a effort - to implement it) and b) we HAVE a more powerful possibility to control it with the script interface! For example with simulavr.tcl. (a simulavr.py is also not a difficult thing) and c) it would be just more code to maintain, but not direct connected with the core and peripheral simulation as simulavr stand for.

But maybe my opinion is wrong! :-) Other comments?

- Do not implement at all!
- Implement only for controller name and clock frequency (maybe, that it's same like simavr to get a program interchangeable) to have a possibility to check/control it and to fix a source of mistakes!
- Implement complete as Markus proposed!

cu, Thomas



reply via email to

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