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