[ELDK] e500mc target architecture

[Valentin Longchamp]

Dear Wolfgang,

On 12/15/2012 11:07 AM, Wolfgang Denk wrote:
> Dear Valentin,
> 
> In message <50CB3A68.9060002 at keymile.com> you wrote:
>>
>> We are now starting a new design which targets the p2041 CPU from Freescale
>> (QorIQ family) and we want to continue with ELDK for this CPU as well. There has
>> been earlier last year a prestudy for this new development. During this process,
>> there was a request from us to add a powerpc-e500v2 target architecture for ELDK
>> that has now been available since release 5.1 IIRC. Unfortunately, we made a
>> mistake for that request, and the correct target architecture for the QorIQ
>> family would be powerpc-e500mc.
>>
>> The straightforward solution would be to add this target architecture again. But
>> I would like to know, what you think is the best approach in this case ? Because
>> of course the generic "powerpc" target architecture produces code that works
>> perfectly fine on a P2041 CPU as well (I have already tested it on the P2041RDB
>> dev board). The drawback is that this code does not really takes advantage of
>> the e500mc cores present in the p2041 cpu. This could however be corrected by
>> adding the "-mcpu=e500mc -mtune=e500mc" (or only one of them) flags in our
>> compile flags.
> 
> Could you please be a bit more specific which "advantage of the
> e500mc cores" you have in mind that would not be supportedby the
> generic-powerpc target of configuration of the ELDK?

I was mostly thinking about all the mechanisms introduced by the PowerISA 2.06
Instruction set. I was thinking that even if the e500mc core is compatible with
the PowerISA 2.03, it would be better to produce code with PowerISA 2.06.

I have mostly ARM experience and there every new core brings a new ISA that
requires a new target architecture to really take advantage of it. Maybe this
influenced a lot my expectations with this e500mc core and how to take advantage
of it.

> 
>> I'm asking because I do not see a lot of variations of PPC cores in the target
>> architecture lists and that's maybe because the above approach is preferred. The
>> advantage of the above approach is that you have less binary ELDKs to manage and
>> maintain. The drawback is that the ELDK binaries in the minimal rootfs then are
>> not really optimized four our target architecture (by the way, do you have any
>> idea of the performance improvement that this would give us ?).
> 
> Do you have any indications that, in this specific case, any such
> additional optimizations exist at all?  If you look at section "1.6
> Summary of Differences Between Previous e500 Cores", and especially
> section "1.6.1 Changes from e500v2 to e500mc" of the "e500mc Core
> Reference Manual" [1] then you will notice that from a software
> development point of view the major difference between the e500v2 and
> the e500mc is the fact that the SPEv2 of the e500v2 has been replaced
> by a standard FPU on the e500mc.  And this exactly what makes the
> difference between generic-powerpc-e500v2 and generic-powerpc.
> 
> I do not see any hints that any other, additional "optimizations"
> were possible software-wise, but I may be missing something.  If you
> have any such additional information, please be so kind to share it
> with us.
> 

Even though most of them are managed by the SMP support of the OS (which
hopefully takes advantage of them), I was (naively ?) thinking that it would be
good (necessary ?) to produce some code that is aware of all the multicore
synchronization mechanisms (some sync/messaging instructions) and HW (CoreNet,
Unified L2 cache, ...) that are all in the list of differences from the e500mc
Core Reference Manual you referred to above.

Best Regards

Valentin