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

[Michael Rolnik <mrolnik@gmail.com>]

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

I will rename them.

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