Re: [avr-gcc-list] simulator

[Bruce D. Lightner]

Jason,

> What kind of simulation speed can you achieve?  I imagine using python
> wouldn't be all that quick.  Whatever is finally included with gdb will
> most definitely require as complete on-chip peripheral simulation as
> possible as well as the ability to add off-chip devices (e.g. LCD display)
> virtually wired to the virtual AVR.  Flexability will be the prime
> requirement (that includes OS independence), speed secondary but important.
> 
> Anyone else got any thoughts on simulators?  Bruce?

As I've told you, my C-based simulator for an AT90S8515 sitting amongst the
PicoWeb hardware is available.  It is well debugged and its speed is good,
running above "real time", depending upon your emulated AVR "crystal".  I've
benchmarked it at over 4 million instructions per second on a ~700 MHz
Pentium III, both under Linux (gcc) and Windows (MS Visual C++).  It's
strictly command-line driven with no GUI of any kind.  A "gdb" connection
would make it much more useful.  

In my "past life" I was involved with a number of microprocessor IC design
projects, which of course required instruction simulators of various
flavors.  We've always found that C-based simulators gave the best speed
while preserving portability.  I've learned a number of tricks over the
years that help to keep the speed up.  As I've told you, I'm committed to
keeping this AVR simulator one of the fastest in the world! :-)

Despite my best intentions, I've not found enough free time from "real work"
to package up the source code and/or connect it to "gdb".  As you know the
simulator emulates the UART (optionally using the PC's serial port) and it
has code for the AVR timers and most of the interrupts.  It does not emulate
the SPI port or the watchdog.  It also has an option to use a "real" AVR
processor to "proxy" I/O via the PC's parallel port connected to the AVR's
SPI port (i.e., using the PicoWeb's "programming" cable).  This runs a lot
slower for all "proxied" I/O instructions due to communication overhead
(i.e., ~10K I/O instructions per second max.), but I've used it to control
the PicoWeb's Realtek Ethernet chip in real time with no problems.

Extending my simulator to support the other AVR instruction sets is pretty
straightforward because the simulator basically uses the opcode tables from
the AVR assembler, after a little post-processing with a Perl script.  There
is a short section of C-code for each opcode.  Only a handful of new
instructions are needed for the "Mega parts".  If connected to "gdb" one
could probably remove a lot of the code that is there now for things like
disassembly and linker symbol table processing.

One of the challanges is to provide for straightforward simulator extensions
for emulation of custom hardware around the AVR processor.  In fact, the
current emulator "knows about" and emulates the PicoWeb's Realtek Ethernet
controller chip and its 32Kbyte serial EEPROM chip.  This is C-code that is
compiled and linked with the base simulator.  A better approach might be to
place this kind of logic in a seperate program and communicate via sockets. 
This would allow emulations written on other programming languages (e.g.,
Python, Java, Visual Basic(!), etc.), even running over the network on
different hosts.  (There is a "fancy term" for this now, namely
"co-emulation" :-)  We had worked out a scheme, including source code, for
the AVR simulator to work this way using TCP/IP sockets, but it got
abandoned early on in the project.

My "free time" is now 100% occupied preparing for a two-week off-road
dunebuggy trip to Baja California starting the second week of October. 
Therefore, I'm not going to be able to work on this until near the end of
the month.  

Best regards,

Bruce

-- 
 Bruce D. Lightner
 La Jolla, California
 Email: address@hidden
 URL: http://www.lightner.net/lightner/bruce/