Re: [Simulavr-devel] SimulAVR + simulated hardware

[Klaus Rudolph]

Hi list,

A happy new year to all members and thanks for the work in the past.

Again I read here that there is a need for a more completed simulator.
As I wrote a long time ago (last summer I think) I have reimplemented
the
simulavr in c++ and added some functionality which is actually requested 
in this thread here. So I offer my work again here and give you a actual
state
of my work, if the team is interested in :-)






"Theodore A. Roth" wrote:
> 
> On Thu, 25 Dec 2003, Bill wrote:
> 
>
> 
> >
> > >>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.

Yes, I agree. If we have external hardware like memories or lcd or uarts
we must have a
way to transfer the logic pin values in a synchronous way. 
This is implemented in my version of 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)

Allready done in my c++ implementation.

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

No! What is with lcd or uarts. The external uarts need a synchronous
data transfer here.
There is no distributed clock which can be used to do an external
synchronisation. So the time
is the only way to give the correct data to/from external device. How we
are able
to get the ready flag from lcd? It needs 20-50 usec for each char. So
how should this be simulated
if we have no synchronous way for data exchange?

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

My solutions is very simple. I have a list of simulated devices. After a
step the device
returns the next time for a step. The sceduler handles a list which
holds the times.
this list is sorted and so only the needed steps are done. That is
simple and
usefull I think. And the best: It allready works :-)




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

Yes, see above.
> >
> > 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.

To transmit time is a hard solution. How it will be handled if the
transmitted time
is in the past? 

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

My external interface will export all data with a netork socket. this
should be
portable. The gdb interface use the same way. I only 
use linux for my work, but If the gdb woks with simulavr on differnt
hardware my
solution for external hwardware should also work.

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

As I use swig for creating simulavr shared object files to include this
into tcl for
writing start scripts, this should also be partable. There is no reason
why that
should not work for python or some other scripting languages.

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

As I wrote: TCL is supported today.


> > >
> > 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 think a gui should not part of simulavr. It is realy enough to make a
public interface
for an external gui, or? What should a gui do? I have only some buttons
to
change the pin state. The rest I use is to writing startup scripts for
simulavr.
In that scripts I configure some devices, the pin connections and the
clock speeds.
Thats all. There is no problem to add some buttons in the script to
handle that via gui at all.
It is only TCL. So it shoudl work and is partable.


> My real push right now is to add internal functionality and provide the
> hooks for external connections.
That work is done :-) 


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

My interfaces are exported and handled by swig. So a big part of 
simulavr behaviour could be handled via scripting languages like
tcl python or some others.


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

There is no change in the code to add the external interface. I only 
change some parameters for eaysier handling. So I dont use the string
class
for parameters and use char*. That  was all what I have changed for the
gui things.
Infact I also do not accept any kind of deeper changes only for the gui
use.


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

I have connected the external devices currently only for "normal pin
operations"
like pins, uarts, spi and so on. If XRAM is needed we must provide a
half cicle
simulation or? There are sometimes 2 state changes in one clock cycle I
think.
But I must read that part of documentation again :-)
 

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

I have simple pins. It is something like that:

Avr8515 device1
Net example1
example1 AddPin [device1 getPin "D2" ]

... some more pins ...

Thats all. That is not the correct syntax here but it shows how it
works.
 


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

Yes. there is no need to configure device internal things. a 8515 is a
8515 and not
a 8515 with differnt port and pin configurations.



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

That is also my problem today :-)


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

I handle that with a simple list of MemoryMebers. The complete memory is
a simple
vector of MemoryMembers. There are differnt kind of Members:
RWMebers, RWWithOwnMemory (they old the 8bit value self) or Members
which interconnect to
the hardware like SREG, or SPL or SPH or all the other hardware related
registers. The Registes will be setup in the constructor and 
where the register is located is given with the vector. memory[xx59]=new
HwSpi(....)


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

As I wrote above. I use a vector<>.


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

I have for each pin in the simulation a set of state vars which hold the 
alternate settings like in/out functionality and so on. When the uart
wants to set a pin to output (Tx) the uart set the state inside the
HWPort class.
For that the constructor of the UART get all the HWPort instances with
the pin
numbers which look like this:
porta= new HWPort(this, "A");
portx= new HWPort(this, "X"); //hanle pins which are not ports like some
timer/comperator pins!
...
uart= new HWUart(this, irqSystem, PinAtPort(portd, 5), PinAtPort(portb,
6) ....9,10,11);
the "9,10,11" is the irq-vector in a 8515 device.

The registers linked against the uasrt:
rw[0x2c]= new RWUdr(uart);
rw[0x2b]= new  RWUsr(uart);

...

Thats all and it is implemented and works fine.


Why I write this again:
I think we have to implementations for now. Some features are only
available 
in one of both. Some people spend time to implement features that are
allready finished in the
other implementation. :-(.

So if someone is interested in getting the naked sources from me (no
./configure, only tested under
linux, not commnted and not an own mailing list :-) and and ugly
makefile which has 
hardcoded references to libbfd for avr.... Send me a mail, I send a
tarball.
If there are more than 2 requests, we should look for a hot and dry
place for the development :-)

If Theodore is interested also, it is maybe possible to get some place
in a second repository? or 
some public background directories?

Thanks for reading :-)

        bye
        Klaus