Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 11/28/19 2:25 PM, Michael Rolnik wrote:
> I don't see why you say that the peripherals are inside the chip, there 
> is CPU within target/avr directory and then there are some 
> peripherals in hw directory, CPU does not depend on them. what am I missing?
> 
> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic 
> <aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> wrote:
> 
> 
> 
>     On Thursday, November 28, 2019, Michael Rolnik <mrolnik@gmail.com
>     <mailto:mrolnik@gmail.com>> wrote:
> 
> 
> 
>         On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>         <aleksandar.m.mail@gmail.com
>         <mailto:aleksandar.m.mail@gmail.com>> wrote:
> 
>             On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
>             <mrolnik@gmail.com <mailto:mrolnik@gmail.com>> wrote:
>              >
>              > This series of patches adds 8bit AVR cores to QEMU.
>              > All instruction, except BREAK/DES/SPM/SPMX, are
>             implemented. Not fully tested yet.
>              > However I was able to execute simple code with functions.
>             e.g fibonacci calculation.
>              > This series of patches include a non real, sample board.
>              > No fuses support yet. PC is set to 0 at reset.
>              >
> 
>             I have a couple of general remarks, so I am responding to
>             the cover
>             letter, not individual patches.
> 
>             1) The licenses for Sarah devices differ than the rest -
>             shouldn't all
>             licenses be harmonized?
> 
>         Sarah,
>         do you mind if use the same license I use for my code?
> 
> 
>             2) There is an architectural problem with peripherals. It is
>             possible
>             that they evolve over time, so, for example, USART could not
>             be the
>             same for older and newer CPUs (in principle, newer peripheral is
>             expected to be o sort of "superset" of the older). How do
>             you solve
>             that problem? Right now, it may not looks serious to you,
>             but if you
>             don;t think about that right now, from the outset, soon the
>             code will
>             become so entangled, ti woudl be almost very difficult to
>             fix it.
>             Please think about that, how would you solve it, is there a
>             way to
>             pass the information on the currently emulated CPU to the code
>             covering a peripheral, and provide a different behaviour?
> 
>         Hi Aleksandar,
> 
>         Please explain.
> 
> 
>     My concern is about peripherals inside the chip, together with the core.
> 
>     If one models, let's say an external (in the sense, it is a separate
>     chip) ADC (analog-to-digital converter), one looks at specs,
>     implement what is resonable possible in QEMU, plug it in in one of
>     machines thst contains it, and that's it. That ADC remains the same,
>     of course, whatever the surrounding system is.
> 
>     In AVR case, I think we have a phenomenon likes of which we didn't
>     see before (at least I don't know about). Number of AVR
>     microcontrollers is very large, and both cores and peripherals evolved.
> 
>     For cores, you handle differences with all these AVR_FEATURE macros,
>     and this seems to be working, no significant objection from my side,
>     and btw that was not an easy task to execute, all admiration from me.
> 
>     But what about peripherals inside the chip? A peripheral with the
>     same name and the same general area of functionality may be
>     differently specified for microcontrollers from 2010 and 2018. By
>     the difference I don't mean starting address, but the difference in
>     behavior. I don't have time right now to spell many examples, but I
>     read three different specs, and there are differences in USART
>     specifications.
> 
>     I am not clear what is your envisioned solution for these cases.
>     Would you such close, but not the same, flabors of a peripheral
>     treat as if they are two completely separate cases of a peripheral?
>     Or would you have a single peripheral that would somehow configure
>     itself depending on the core it is attached to?
> 
>     I hope I was clearer this time.
> 
>     Aleksandar
> 
> 
> 
> 
>         I don't see any problem from CPU's perspective.
>         as for the sample board is just a sample, I hope other people
>         will create real models or real hw.
>         there was no way I could provide a CPU alone, that's why there
>         is sample.

If I understand Aleksandar correctly, the naming is incorrect because 
too generic to AVR family, why Sarah only modeled the Atmel implementation.

Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c 
(similarly with the macros) would be enough Aleksandar?