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

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

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

On Sunday, December 1, 2019, Aleksandar Markovic <
aleksandar.m.mail@gmail.com> wrote:

> 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.
>
>
I meant to say the renaming is not appropriate. Sorry for confusion.


>
>
>  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: 9685 bytes --]