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
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/simulavr-devel