[Simulavr-devel] Multiple CPU - Architecture discussion

[Knut Schwichtenberg]

Hi Gang,

I would like to start a discussion about the future architecture of the multiple 
missing AVR-CPUs. I know that several CPU-specific details have to be clarified 
- different EEPROMs, Timers, missing USI, ...

But at the end we need to have a solution how to initialize a specific CPU. I'll 
start with my thought to this issue:


Currently we have one module per CPU such as atmega128.*. I'll call this method 
"Hardcoding". The object file size for the program varies from 12k byte to 20k. 
Thinking of aprox. 100 AVR CPUs NOW it will become a lot of maintenance work and 
extend the program by ~1Mbyte. There might be alternatives like a data array per 
CPU and a "factory" that initializes a CPU based on one specific data structure 
- but that is an implementation detail.

As an alternative configuration files could be used. The file format could be 
either XML or the MS-common "config files" or something individual. This 
solution needs also a factory which allows to initialize a specific CPU. 
Therefore it is close to the Hardcoded data-array solution above.

The main question is: Where do we get the input to create the files (either 
Hardcoding or Configuration Files)? My first idea are the "Partdescription 
Files" from Atmel's AVRStudio. These are XML-files describing twice(!) several 
CPU specific information per file. There are some drawbacks in using these files:

1. License
Direct use of these files is only allowed in the context of the AVRStudio. That 
might be funny for Windows-users, but they will not / can not use simulavrxx. So 
a translation / conversion is necessary.

2. Incomplete Pin assignment
The Partdescription files do not have an assignment from functions to a Port-pin 
(OC1A -> PORTB Pin5). To solve this problem by software the "pin configuration" 
needs to be available as a table - not part of the ATMEL CPU documentation :-(. 
The pin assignment has to be added manually!

3. Incomplete / unspecific function
As described above and as one could see in the development of avr-libc the 
peripheral components have changed their function but have kept their names. So 
based on the name one can not distinguish if it is for example the Watchdog of 
the '128 or a newer one! This have to be added manually! (At the moment there is 
no complete overview of all CPUs and all peripherals and the specific function 
available - hope ATMEL knows it...)


As another alternative of input instead of the Partdescription files we could 
use the avr-libc header files. With the exception of a more compressed 
information and not need to learn XML it is a derived source of the 
Partdescription files. The License issue is handled but point 2 and 3 of the 
list above remain unchanged.

While writing some examples based on Atmels AP-Notes I saw that bit assignments 
in suimulavrxx are hard coded, such as MPCM = Bit 0 in UCSR* of the M128. I 
think that it might be necessary to check if ATMEL HW-designer have moved some 
bits around...

So here are my questions to the group:

- Has anyone checked if functional identical bits kept their locations
across all device families Tiny, Mega, XMega,..?

- Are there any ideas of other sources for the CPU configuration? (I'm thinking 
of a automated process. Manually is always an alternative for volunteers!)

- What are benefits / limitations for a "Hardcoded" architecture?

- What are benefits / limitations for a configuration file architecture?

- Is there an alternative to these both architectures?

Specially for the configuration file implementation:
- XML or Config-File what seems to be best?
(For the config-file are of course PD-implementations around so no need to use 
M$)


Cheers
Knut

BTW: If there are documents / information around that should not be made public 
please send me a personal mail.