Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Philippe Mathieu-Daudé]

On 11/28/19 11:20 AM, Aleksandar Markovic wrote:
> On Thursday, November 28, 2019, dovgaluk <address@hidden 
> <mailto:address@hidden>> wrote:
>
>     Aleksandar Markovic писал 2019-11-28 12:28:
>
>         On Thursday, November 28, 2019, Philippe Mathieu-Daudé
>         <address@hidden <mailto:address@hidden>> wrote:
>
>             Add famous ATmega MCUs:
>
>             - middle range: ATmega168 and ATmega328
>             - high range: ATmega1280 and ATmega2560
>
>             Signed-off-by: Philippe Mathieu-Daudé <address@hidden
>             <mailto:address@hidden>>
>             ---
>
>
>         Philippe, hi.
>
>         Thank you for the impetus you give us all.
>
>         However, is this the right direction?
>
>         Let's analyse some bits and pieces.
>
>         Starting from the commit message, the word "famous" is used, but I
>         really don't see enumerated CPUs/MCUs are any special in Atmel
>         lineup.
>         Other than we often used the doc describing them (cited several
>         times
>         in our discussions) as our reference, but that doesn't make them
>         "famous". Ofcourse, there other docs for other Atmel CPUs/MCUs,
>         of at
>         lest equivalent significance. For example, "tiny" ones are at
>         least as
>         famous as "mega" ones.
>
>         Then, you introduce the term MCU, without proper discussion with
>         others on terminology. In parlance of QEMU, ATmega168 at al. are
>         CPUs
>         (we all know and assume that that are some peripherals in it). I am
>         not against using the term MCU, but let's first sync up on that.
>
>         The added terminology trouble is that MCUs, as you defined them,
>         have
>         in array atmega_mcu[] a field called "cpu_type" - why is that field
>         not called "mcu_type"? *Very* confusing for any future reader. And
>         then, similar terminology conundrum continues with macro
>         AVR_CPU_TYPE_NAME().
>
>
>     MCU is a system-on-chip which includes CPU core and peripheral devices.
>     Separating this is better that including everything into the machine.
>
>     E.g., different MCUs may have different IO addresses for USART.
>
>
> Pavel,
>
> Do you know how is this resolved for other platforms?
>
> How other platfirms organize and use terms "soc", "mcu", "cpu",  "core", 
> "cpu core"? And what is the relation between each of them and QEMU 
> command line options "-cpu" and "-machine"? Is thar organization the 
> same accross all platforms?

The market/industry evolves quicker than the QEMU codebase, so some 
technical namings that were fine 14 years ago might be not sufficient 
nowadays.

QEMU started with dies/chipsets being really only a 
CentralProcessingUnit, cache managed off-die, external RAM, external 
peripherals.

For example the R4000 is a CPU with internal cache but QEMU doesn't 
model caches.

Now compare that with the I6500. Is it a CPU? Yes and no...
It has 4-6 cores (each having its own ScratchPad RAM), each core having 
various threads (now 'thread' == QEMU MIPS CPU), there are peripherals 
dedicated to inter-core communication; then there is also some I/O 
coherence units to use external peripherals. Add to that you can 
clusterize the cores :)
All that in the same die. The industry calls this 'System-on-Chip', 
abbreviated SoC.
Actually the 'SoC' abbreviation is used as it by MIPS marketing:
https://www.mips.com/products/warrior/i-class-i6500-multiprocessor-core/

  "As such, in conjunction with popular third party SoC coherent
  interconnect/fabric alternatives, the I6500 family can be used
  in “many core” implementations of up to 64 clusters, or >1500
  processing elements (up to four threads/core, up to six
  cores/cluster, up to 64 clusters)."


MCU and SoC are similar in that they contains CPU and peripherals in the 
same die.


Now the QEMU codebase has various 'subsystems' of interests. Group of 
developers are custom to work in the same subsystems. When I'm writing 
code/comments targeting a specific group, I try to use the technical 
vocabulary used by the group, often based on the subsystem technical 
documentation available (specs, datasheets). This is why here I used the 
MCU terminology.

> (I am asking you as you most likely have much wider experience in the 
> topic, sincr mine i limited to mips emulation)
>
> Yours, Aleksandar
[...]