In working with the 5121e and 5123, it has become evident that there are some additional complexities when developing software for the different cores found in this SoC family. Here, we have an e300 core and the AXE engine. In our case, the AXE code needed one compiler and the e300 code another. The AXE code was written in assembly language, the e300 code in C. The two independent cores are doing different things and need to communicate perfectly to have everything run as required (and efficiently) when everything is binary.

Just thinking ahead, but it seems we may have some particularly useful discussion here on this subject in the months ahead.

If you have had some of your own multicore experiences others may find interesting, please post them here. Thanks!

R&B :-)

P.S. And, then there is the MBX graphic core. Eventhough it is not freely programmable, it adds another layer of sophistication to the challenge. Whew!

Hi,

Sounds like fun :-)

In the past, I've written multi-threaded software on a regular basis, but not often for asymmetric systems.

This would be a project I'd like to work on, the only problem I have is a serious lack of time.

In any case, I'll be here to offer my support whenever I can.


Best regards,
Johan

This is very true: The MPC512x family is one with a triple core. Very interesting and... complicated!
It would be a pity if not all three cores (or, at least, e300 and AXE) were put to good use because of bad development tools. These tools are a must for a product to be a success: It has to be a success first for developers. A certain Redmond-based company got this right since many years ago.

Can anyone here tell about the differences between 5121e and 5123? I've been flicking between these two pages in the freescale site, and I can't find any difference... Hey, wait a moment, there's that document from last year's FTF...

No PowerVR MBX in the 5123. That is all.



We will not be throwing any chairs or dancing around like apes because of this. You guys know what you're worth already :)

And that's exactly why I feel drawn to making a project proposal in this area. Complicated, yes - but so much fun to work on something relatively uncommon like that :-)


Johan.

I've just learnt that freescale uses CodeWarrior toolchain, which already has libraries for using the AXE, even some audio codecs are already done. Meanwhile, we are struggling with GCC. Does it make sense? Can CodeWarrior be included with the development systems that Genesi provides?
Now, I should learn about CodeWarrior...

At this point CodeWarrior does not have what is needed. Multicore/different core programming requires a deeper understanding. The steps involved in translating an 'instruction book that solves a problem' into machine readable code are not best served by an out of the box tool kit. We are pleased to see the interest in this topic, as there are challenges to overcome.

R&B :-)

Well, Amiga developers were able to make use of PowerUP accelerators, so throwing in an alien CPU in an existing system is now new to them (us?).



I don't understand this. From what I've learnt today, freescale claims that this toolchain already has libraries to put AXE to good use.
The e300 core has to generate "alien" AXE code, put it into the AXE's memory, and issue a reset on it, so it starts executing. If that's all that freescale provides, someone should write the equivalent of the PowerUP library, in order to make the AXE an adjacent operating system, ready to accept tasks.

But my understanding is that this wouldn't be needed, because freescale already has a kernel ("scheduler") running on the AXE, and also an API to send tasks to it. Is this true or not?

Yes. Freescale have the right to sell these things to their customers that need them, and some of them require licensing which Freescale must be careful not to infringe by selling a codec or something to someone who is not licensing it (for the case of encryption and Windows Media, this is very true).

However, a C compiler does not adequately extract the power of the AXE core. It is quite cleverly designed to do what it does, and as such to get best performance it needs hand-scheduled assembler code. Of course this can be written in a C compiler, and assembled and linked into an ELF file, and loaded into the AXE core like any other program (you may have seen this method on Cell for the SPUs)

ColdFire - even gcc - won't help. And you must think of the ways to use the AXE programs as best fit at the time you're using them. It is a lot more than having 10,000 embedded, loaded tasks which can run at any time, and expecting them all to run at once, decoding an mp3, a video file, doing SSL for your web browsing session, XOR for your RAID. It needs to be properly scheduled and coordinated. You will trade off certain features for others.

The only experience i have with multicore is with the nintendo ds. There you have 2 possibilities.
A) you use some shared memory (http://www.double.co.nz/nintendo_ds/nds_develop6.html)
B) you use the built in fifo queue (http://www.double.co.nz/nintendo_ds/nds_develop7.html)
I haven't done a thourough read on the documentation yet so i do not know if method B also applies to 5121e. But method A should work.

Using that a library can be made that runs on the axe and recieves commands from the a300 on what it should do. http://www.double.co.nz/nintendo_ds/nds ... hot_sample)

[edit]Method B is also valid accounting the documentation of the axe. And i start doubting on method A.[/edit]

Development can be done independently. The library can first be designed to work on the e300 core and later be written and optimized to run on axe. E.g. OpenAL would be a candidate for that.

It's somewhat similar.