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

[Aleksandar Markovic]

> 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 <address@hidden> 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 <address@hidden> wrote:

On Thursday, November 28, 2019, Philippe Mathieu-Daudé <address@hidden> 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 <address@hidden <mailto:aleksandar.m.mail@gmail.com>> wrote:



    On Thursday, November 28, 2019, Michael Rolnik <address@hidden
    <mailto:address@hidden>> wrote:



        On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
        <address@hidden
        <mailto:aleksandar.m.mail@gmail.com>> wrote:

            On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
            <address@hidden <mailto:address@hidden>> 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