Re: [Simulavr-devel] Python again ;-) and some other things

[ThomasK]

Hi Onno,

now I want to answer your posting :-)

> How do you model external hardware/periphery of the AVRs? I am very interested 
> in this,
> because I think that there is a lack in simulations for external components ...

In the moment, for my unit tests, I don't need really a functional 
external model. A normal test with, for example, an external clock input 
isn't complicated: run target till a breakpoint or time or amount of 
steps, set external pin, run again till breakpoint or any, test response 
and so one. The process is similar to a GUI ontop of simulation core. 
GDB interface works similar, make some steps or run till breakpoint, 
check response, set values and so one.

> and I like to know how others do it. I connected simulavrxx to icarus verilog
> and in my private branch, I have it also working for verilator, which is ...

Your problem looks a little bit more complicated. Main task is to 
sychronize 2 simulators. There are 2 possible solutions, depending on 
time precision. If time precision isn't a problem, then such solution 
like the ui-interface in simulavr is possible. There is a network 
connection between this 2 simulators and every part sends his changes on 
external pin's to other or receives changes from other and inject it in 
the own core. If there are no timing constraints it's a good solution 
and with a good description from network protocol (like remote serial 
protocol for gdb) it's also possible to connect other programs for other 
goals.

But if time constraints are necessary, then the main problem is that: 
you have 2 simulators which have a "mother of all time" :-) but, 2 
mothers will make trouble. ;-) So the task is to find a solution to 
connect one simulator to the master time controller of the other.

I don't know, how you connect icarus verilog/verilator and simulavr now 
in your current solution. Can you describe it for me? I know, that there 
are some extensions for icarus to connect something with icarus. (if I'm 
not mistaken, it's called co-simulation) Such hardware simulators are 
based on a exact time behavior, as I know. So it would be good to know, 
how it's solved there, which part takes the master time controller and 
how communication is solved there.

> I think this functionality overlaps partly with a patch I have made 
> (the one on the savannah tracker is now seriously outdated btw. but did not seem to generate
> any interest anyway) which basically
> implements a new tracing infrastructure in simulavr and allows to write
> state change data (currently only value change dump, but my new version is 
> extensible).

Trace output is, in my opinion, also a part, which could get some time 
to rewrite or implement some new ideas. As I assume, trace is used 
mainly for debugging purposes, necessary for developing new 
features/hardware/functions for simulavr. But not really usefull for 
users of simulavr. (or there are other and better posibilities) So I'm 
not sure (if it is so!) that it makes sense to spend much time for it. 
If it is interesting for an user to get this trace output, then it looks 
for me as a good idea to think about some rewritings/extensions for 
trace. Ideas?

> And CVS branches are a PITA or will quickly become one.

I agree with you. I have seen, that savannah supports not only CVS, also 
 subversion, git and (it's my personal preference ;-) ) mercurial. But 
it's a common discussion. I know CVS, subversion and mercurial. 
subversion, git and mercurial (and I think, also bazar) are task based 
instead of file based like CVS. My experience in big business projects 
is, that file based VCS brings a lot of extra trouble. If all here agree 
to switch to an other VCS, then it would be a good idea to do that. If 
not, then it could be a possibility to set up an new repository as an 
follower to simulavrxx CVS repo, means, that changes from simulavrxx 
will be transfered to the new repo as base trunk, so "individual" 
development branches are possible. But there is one disadvantage: 
changes, which should be inserted in this base trunk, have to be manual 
transfered back to CVS and then retransfered from CVS to the new one.

One word to development branches: to give "everybody" possibility to 
create a new branch is also not a good idea. There should be one main 
trunk, release branches for urgent bugfixes in this releases and a few 
well known development branches. And if a special development is solved, 
this development branch is to merge back to main and to close. If not, 
you will get a big tree and many confusion. But how to deal with 
individual development? (I don't know, how it is in GIT, maybe there is 
a similar feature) For example, in mercurial there is a extension named 
MQ. It makes it possible, to hold one or more individual changes on top 
of an official repo. So, individual changes will have also VCS and a 
simple possibility to merge back to official repo, if necessary. Only my 
opinion and proposal!

> I do not think that this is a good idea, I'd like to have a coding standard.

Me too! :-)

> Great, maybe I can snatch some of your code for my Atmega8 :-) Did you
> look at my python device generator code?

Why not? That's the meaning of open source, I think. Python device 
generator code? Where it is to find?

I'm hungry ... ;-) cu, Thomas