Re: [Simulavr-devel] simulavrxx plugin interfaces

[Michael N. Moran]

Klaus Rudolph wrote:
> Yes, the actual situation is that there a lot of simulators are on the 
> "market" and also open source ones. And some of them implement some kind 
> of "outside world" interfaces and some devices for that kind of 
> interface. There is a total lag of "standards" I think. Ore the existing 
> ones are not fullfilling all requirements. For my! purpose I need a very 
> fast simulation. One of my design target was simply speed. Most of 
> things could be implemented in a much better "object oriented" way with 
> less "side effects". But I had not found a "better" way to do it as fast 
> as it is in the moment. I need! simulation of 20 and more cores with a 
> real environment to do full integration and system test. And my last 
> simulations run more than 24 hours on my pc. We had sometimes discussed 
> cleaner solutions but could not find a match for speed and claerness :-(.

Some years ago, I needed a CPU32+ simulator which
supported various hardware devices. I found a
"public domain" 68K simulator and spent some time
modifying it to support the CPU32+ instruction set,
and the ability to use various peripheral hardware.

The most important items I found were 1) abstracting
memory accesses (for I/O) 2) interrupt handling and
3) supplying clock cycles to the simulated peripherals
so they could behave independently with respect to the
CPU simulation.

Once I had these interface classes (C++), adding
peripheral simulations was more about describing
the behavior of the peripherals ... not an easy
task!

With the exception of timers, most peripheral
devices have interfaces to an "outside world",
which can be either digital or analog. In my
case, I only needed UART and HDLC data streams,
and I used sockets that allowed me to connect
these interfaces to other processes on my *nix
system.

The simulator proved very useful in development
of my operating system, and later in working
on a large telecom product that used CPU32
processors before we had target hardwaree.

Later, I looked briefly at doing something
similar with a powerpc processor, but when
you get into RISC, caches, MMUs, execution units
and pipelines ... well never mind ;-)

One other thought, is that having a plugin
architecture for "device" simulations would
be nice for extensibility. Since devices
are attached to address/control/data/interrupt
buses, and require clock cycles to operate,
there's your general plugin interface. But
I never have "enjoyed" DLL hell :-P

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1