Re: [Simulavr-devel] SimulAVR + simulated hardware

[Theodore A. Roth]

On Thu, 25 Dec 2003, Bill wrote:

> Is there a better way for me to respond below? I suspect this won't be 
> pleasant to slog through...
> 
> Theodore A. Roth wrote:
> 
> >On Wed, 24 Dec 2003, Bill wrote:
> >
> >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.
> >
> Ok...I must confess I don't know enough about the refactoring you are 
> talking about to understand this...

Refactoring basically means changing the implementation without changing the 
behaviour.

> 
> >>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?
> >
> >  
> >
> If a simulation of a physical system is more time intensive than 
> simulAVR, then Simulavr might run "faster than real-time" relative to 
> the pysical system under control....this is a problem becuase the 
> dynamics of such a system rely critically on time being corelated.
> 
> I don't plan on doing this until I get experience with these tools for 
> the coombinatirial type projects I have in mind (chess clock, 
> play/recorder-organ, etc) but even the act of detecting the organ's 
> tempo and adjusting playback to match the input tempo might be easier to 
> test/debug on the simulator if time could be correlated.
> 
> It's not a big concern of mine, and I don't have concrete ideas yet of 
> how to work with these concerns...perhaps my whole concept is 
> out-of--whack, it's not something I have much experience with yet, but I 
> don't see how simulated hardware can be time-independent from simulavr 
> in useful dynamic-control type systems simulations.... I'm thinking of 
> an inverted 1-(or is it 2?) dimensional inverted pendulum, for example.

Ok, I don't think it will be too hard to pass time in both directions. It 
probably just means adding another function argument.

> 
> >>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.
> >
> I am planning on WxWindows, probably via WxPython for my GUI 
> tinkering...(otherwise just WxWindows from C++) I don't see anything 
> incompatable here...

Just to clarify. I'm not too excited about actually putting GUI into the 
simulavr source proper. I'm fairly biased toward GTK+ and python at the 
moment and I really don't want to force my preference on any one. The hope 
is to allow the user to use the toolkit of their choice without the API 
getting in the way. The other reason to avoid adding GUI code to simulavr is 
maintenance. I can't support multiple toolkits and things will bit rot very 
quickly.

If people wish to contribute GUI plugins, there should be a contrib 
repository to keep those available and it would be up to the contributor to 
keep them up to date and maintain them.

My real push right now is to add internal functionality and provide the 
hooks for external connections.

> 
> >>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 

I've been trying to keep the dependencies of simulavr to a minimum. Right 
now, you need python to run the test suite, but that is "soft" dependency 
since you can build and use simulavr without python.

> >>.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.

Yes. Also, for memory mapped devices, you should be able to install a vdev 
provided by a plugin into the XRAM space.

> >
> >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.
> >
> Hmm..something here sounds off, but I cannot put my finger on it... I 
> agree that we should be able to "rewire" a simulated LED circuit 
> toanother pin via a configuration file of some sort.....then again, an 
> API for that might be appropriate too...

I was confusing pins with register addresses. There's really two levels 
here. First is tying pin to the internal register bits. This should be done 
in the device configuration and should be fairly invariant. The second is 
connecting a pin to an external device. This should be done in the config 
file.

> 
> >>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.
> >
> I know I'm new to this, but I'm curious about what mistakes/lessons you 
> are referring to...Are there previous threads I can  review?

I don't think this has really been discussed much on the list. Here's the 
big issues that I'm currently working on with the mem/vdev rewrite:

When I started simulavr there were not any devices with extended IO
registers. That isn't handled too well at the moment.

I also assumed that IO registers would be at continuous, sequential 
addresses. That hasn't turned out to be true.

The decision to make the sram memory space a linked list of VDevices was a 
bad one. It's just too slow and getting slower as new features are added.

> 
> >>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.

Thinking about this more, I'm not sure now. There may be a need to use a
bit stream to allow simulation of framing errors and such. I'm not sure on 
this one. There's also the timing issue since in reality, the bits come out 
of the port considerable slower than the cpu clock rate. Sending all the 
bits at once compresses time.

[snip]

> >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. 
> >;-)
> >
> I used something out of CVS from a few months ago..I couldn't tell you 
> exactly what. I just know that there was some feature in CVS that I 
> wanted that wasn't in the latest tarball...

The version number in configure.ac should contain at date stamp (e.g.  
20031203 is 03-dec-2003) of the day of the last commit while released
versions don't have a date stamp.

Ted Roth