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

[Onno Kortmann]

Hi Thomas!
> 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.
Sure: In the current implementation, Icarus Verilog is the mother clock source
and simply drives the ->Step() method of any avrdevice. After each step,
the outputs are checked for any changes and new input values are applied.

For verilator, a very similar way is taken. 

As the time scheduling principle in verilog allows to run with multiple
clock sources, I figured that this would be the easiest way to combine
simulation of AVRs with the rest of verilog. 

> 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. 
Well, I am in the process of rewriting all the read/write register handling
in simulavrxx and I hope to put it on github.com soon (see below).
Basically there will be a map of string names to all registers (real ones and 
shadow regs,
as far as needed), and tracing can be enabled for each individual 
register (without any additional CPU perfomance penalty if not enabled compared
to current simulavrxx code). Simulavrxx will use a bit more memory, but
I do not think that this is a problem.

> > 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.
For me, it's the other way around (I know git but no hg) :-)
But as there seems to be a connector for hg to git repositories,
I would suggest that we at least have the public repo in git format,
transparently accessible to you :-)

> 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.
I agree. But transferring patches through savannah's interface is even
harder, so I think this is not the biggest problem here.

> 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.
ACK. OTOH, with FOSS, everyone can make his/her own fork... :-)

> 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!
ACK for functionality, in git there is git rebase for internal stuff
and topgit for internal and public stuff, which I think
is similar to what you propose.

> > I do not think that this is a good idea, I'd like to have a coding standard.
> 
> Me too! :-)
So I would suggest that we first throw all bits together which we have (to ease
merging) and run the whole code through 'indent' then. 

> Why not? That's the meaning of open source, I think. Python device 
> generator code? Where it is to find?
I am currently cleaning up my patches and pushing them to my already existing
git repository (which I put there after the savannah crash). It is at

http://github.com/onnokort/simulavrxx/tree/master

I hope I can use the evenings of the next week to put the rest of my code there,
unless one of the maintainers here says 'stop the fork' :-)
If you give me your github id, I can add you to the list of collaborators.

Greetings,

onno