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

[Aleksandar Markovic <aleksandar.m.mail@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6866 bytes --]

>
> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c
> (similarly with the macros) would be enough Aleksandar?
>
> On Thursday, November 28, 2019, Michael Rolnik <mrolnik@gmail.com> wrote:

> I will rename them.
>

AVR is the name of a microcontroller lineup, and Atmel is the name of the
company that started producing them. Atmel was recently acquired by
Microchip, so thw word Atmel now does not even exist in new specs.

Taking this into account, I don't think renaming

hw/char/avr_usart.c -> hw/char/atmel_usart.c

is not appropriate. Renaming macros, too. The current names are fine, for
now.

A separate but related naming question will show up later in future, when
we, let's say, want to implement two different version of a peripheral
(let's say USART), one as specified for older microcontrollers, and one for
newer.

But, OK, let's leave that for future.

Regards,
Aleksandar



> On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic <
> aleksandar.m.mail@gmail.com> wrote:
>
>>
>>
>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé <philmd@redhat.com>
>> wrote:
>>
>>> 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?
>>>
>>>
>>
>> Some renaming could help, perhaps not quite like the one above, but my
>> point (which I find hard to believe I can't explain to you) is that
>> peripherals inside the chip evolved over time, as starkly opposed to
>> external peripherals that are set in stone...
>>
>
>
> --
> Best Regards,
> Michael Rolnik
>

[-- Attachment #2: Type: text/html, Size: 9121 bytes --]