Re: [Simulavr-devel] SimulAVR + simulated hardware

[Theodore A. Roth]

On Wed, 24 Dec 2003, Bill wrote:

> I"m interested in learning about how to write simulated hardware for 
> simulavr. For proof of concept and to hopefully keep the task 
> manageable, I'd like to start with simulating a few LEDs and switches.
> 
> How should I start? Who's interested in this topic?
> 
> 1.)TRoth was kind enough to point me to README.ext_int and 
> README.mem_vdev, but unfortunately, I can only find the README.ext_int file.
> 
> 2.)It sounds like a plugin-architecture is the intended direction for 
> what I'm describing. What would this look like/how can I help?

I've been thinking about this a lot lately and my initial inclination is to 
add function pointers to the vdev structure to provide up to 3 hooks for 
read and 3 hooks for write access to a given address.  One hook for the main 
function of the address and two for alternate register/pin functions. Almost 
all the pins of an avr have multiple functions. The hooks would provide 
external input when the register is read and output when it is written to.

My planned refactor of the memory/vdevice imlementation precludes this 
though.

> 
> It seems the first thing to think about is what the design goals are:
> 
> A.) For me, I'd say that there must be a way to synchronize the 
> simulated hardware with simulAVR. At least the internal interrupt should 
> be supported (not I/O related, per se, but the concept of time should be 
> supported across the I/O interface in both directions)

Why would time need to be sent in either direction? In a real application, 
time is not shared unless you have multiple devices running off of a single 
crystal.

At most, I think that the sim may sent a clock tick count out the interface. 
In that case, the external hook can examine the count and see if it needs to 
update it's value. I can see that being useful.

Do you have an example of a case where the hook would need to pass clock 
info back?

> 
> B.)how portable does this plugin architecture have to be? I'd like to 
> see at least Linux (x86, if it matters) and at least cygwin or MINGW 
> support.

It should be as portable as possible. I also want it to be generic enough to
allow a user to write custom plug-ins using what ever language they desire
(perl, python, ruby, C, C++, tcl/tk, etc). I think that a C API with shared
ojects (DLL's in windows land) would be the most portable (using libtool).

For GUI plug-ins, I'm still not sure on that. GTK+ seems to be making 
strides in portabilty. QT I have a problem with since you have to pay for a 
license to develop on windows with it. Tk via tcl, perl or python could be 
relatively painless.

> 
> C.)the README talks about a config file... I agree we should avoid 
> writing any parsers...there are so many already available. My vote would 
> be for either Python (I have some toy experience with this ala SWIG) or 
> GUILE (less experience, but have been through tutorials to laod/execute 
> .so, I think via SWIG also) What whoudl this config file do though? I 
> would assume it would configure how a plugin hooks up to theh virtual 
> pins of the AVR chip.

My intention with the config file was to allow a user to define which 
plug-in (e.g. an LED) to connect to which bit(s) of which address. This 
would make the plug-in more generic instead of having a plug-in tied to  
specific addresses and/or pins.

> 
> D.)the actual API of course needs to be worked out. My initial interest 
> is(maybe only) in AT90S8515. This could be interesting since on the 

I'd rather approach it from a more generic point of view. I've already made 
some bad design decisions based on only looking at one or a few devices. 
It's a pain, but we really need to look at the big picture when adding new 
features. This is another motivation for my mem/vdev refactoring.

> surface, there are ports A-D, but of course, the pins for ports A-D can 
> be used to access built-in functionality such as UART, interrupts, 
> external memory, etc.. To me this means that the same pins might 
> likewise have different interfaces. It doesn't make sense to simulate 
> the hardware signals involved with RS-232, it should just look like a 
> byte (word maybe, given 9-bit mode?) stream, right?

I hadn't thought about this yet, but I like the idea of sending a 16-bit 
word out. It could even contain the start, stop and parity bits if needed.

> To address TRoths' concern, a sample syncronous plugin could be provided
> to show how I/O signals could be buffered to allow asynchronous
> interaction with the AVR chip. This section seems to require a document
> that specifies the API.  Lots of work to be done here I think!

Definitely a lot of work to do.

> 
> My short term project is a chess-clock.
> My long term project is to simultaneously record/playback music on an 
> old Hammond Organ. That's 44 keys per console plus 13 pedals, lots of 
> toggles, tempo adjustment (probably sense only) and a few other things 
> to make it all work nicely... It's an electronic organ, meaning no 
> microprocessors in the organ. It's mostly analog except for an EEPROM 
> that sequences the rythm unit...and likely sensitive to noise I expect 
> to be present in a AVR-cirtuit, wihch I think I have several solutions 
> for already. Anyway, my father built it from his junk, discard and 
> garage-sale piles when we worked at Hammond organ.  I exepct to find 
> many projects come up as I learn how to use the AVR chips.

Sounds like some fun stuff.

> 
> 
> Ok. I've rambled on a bit and will likely be on-and-off given vacation 
> plans coming up. But I wanted to get this thread started at least for my 
> own peace of mind.
> 
> I'm not used to this type of development, but hope to be of some use to 
> this project. I've investigated the existing instruction (opcode) 
> simulation code, displapy coprocess driver, and a little bit of the GDB 
> interation code. The design definitely looks workable.

Just for my curiousity, which version of simulavr are you looking at? 
Hopefully you are looking at the cvs now that savannah is mostly back up. 
;-)

> 
> Comments? Concerns? Suggestions?

See above.

Ted Roth