Software migration from for C6416 to C6657

I will give this a quick shot on this forum and then copy my response on the BIOS forum - answers inline with your questions:

I started using the CCS5.4 for some initial tests. From what I have found till now, my questions are:

[Eric] - start with the latest CCSv6. Tons of updates, newer Eclipse platform, honestly - don't even consider starting this project migration with anything but v6.

- C6657 is not compatible with DSP/BIOS, upgrade to SYS/BIOS is mandatory, right?

[Eric] - correct. All new C66 devices support SYS/BIOS only. The O/Ss are very similar in operation but very different in terms of configuration (.tcf vs. .cfg files). You still have a decent GUI to use in SYS/BIOS and there are many new features that were not available in DSP/BIOS. If you need an introduction to SYS/BIOS, I highly suggest you attend the "Intro to TI-RTOS Workshop" or at least watch the videos. Links to everything is here:

http://processors.wiki.ti.com/index.php/TI-RTOS_Workshop

- C6416 is not compatible with SYS/BIOS, so it is not feasible to test SYS/BIOS first at C6416, right?

[Eric] - the C6416 was based on the C64x CPU which only supported DSP/BIOS. The next generation C64x+ (note the PLUS sign) began supporting SYS/BIOS. It was a timing thing. SYS/BIOS came out and was fully supported POST the date of the C64x+ architecture, so the BIOS team decided to go backwards only to the C64x+ CPU and all future devices. As the C66x was introduced, the decision was made to only support the latest RTOS - SYS/BIOS and NOT support DSP/BIOS on newer C6x devices. 

- C6416 code uses COFF format in some assembly code, should this be changed to ELF? Is this mandatory? Is there a CGT, SYS/BIOS version compatible with COFF?

[Eric] - COFF (object file format) has been around a long time. Over the past few years, we have transitioned to ELF for all newer devices. Some, today, still support both - like the C6748. However, the later support packages (like the MCSDK) are only ELF compatible. C66x is all ELF. Yes, it is mandatory to switch to ELF. There are new features, but the biggest difference that may affect code dev't is that the LONG data type is 32 bits in ELF where it was 40 bits in COFF. So if you used long data types, this can get a little sticky. If you used the generic types (like uint32_t), you're fine. Because you're moving to C66x and SYS/BIOS, this automatically means you will be using ELF object format.

- Do you suggest a combination of compatible releases SYS/BIOS, CGT, SDK in order to need the minor changes?

[Eric] - use the latest IDE - CCSv6, latest CGT and latest MCSDK for your new project in C66x. There are also build tools available to build outside of CCS like before. You will most likely use gmake and run that on your own makefile. There are wiki sites dedicated to showing you how to do this:

http://processors.wiki.ti.com/index.php/Projects_-_Command_Line_Build/Create

- Will I need mandatory code changes to move from single core to dual core? Optimum performance is not the question for the moment.

[Eric] - while the ASM code you have will probably work on the C6657 (backward compatible), I highly suggest you use the C source code version of that ASM and re-build it with the new compiler. This will make use of all the new architectural features on C66x core. In the old days, we sometimes had to create ASM functions called by C due to performance issues. However, the compiler these days, esp for C6657 is so much more advanced, there is no need to write ASM for C6x devices. Just follow the std coding technique of using the Debug build configuration first, then switch to Release, then continue to add pragmas and -o3 later to squeeze out more performance. I also have a 2-day training course (with videos) on the architecture and compiler/optimizer that will jump start you on how to use the compiler and provide a basic understanding of the cache, CPU architecture and EDMA3 if you so desire:

http://processors.wiki.ti.com/index.php/C6000_Embedded_Design_Workshop_Using_BIOS

- Are there additional issues besides the above which I should take in mind?

[Eric] - I don't know the application, but some applications work better using Core0 as the master and Core1 as the processing engine. Others work better pipelining operations across both cores. I am sure there are wiki sites that address this as well. Also, download the MCSDK and familarize yourself with it. This will be your main SDK that you will interface with.

- In what order do you suggest I should do the changes? (configurations, SYS/BIOS, CGT, CSL, ...)

[Eric] - I think you should start with the O/S since this is the backbone of the migration. Create a new SYS/BIOS project, add an Idle function for test, one Hwi (you can trigger that without hardware using Hwi_post() and work on one piece/thread at a time. Build your project up one major piece at a time without peripherals and then begin to add that comm in. Solving one problem at a time. IMHO.

- Are there available documentation, guides from TI for some of the above for the migration?

[Eric] - all docs for C665x are here - every link imaginable regarding your processor of choice:

http://www.ti.com/product/tms320c6657

Till now I have only found "Migrating a DSP/BIOS 5 Application to SYS/BIOS 6" SPRAAS7G and not much in the forum for SW migration.

[Eric] - there is a migration guide for the OS as you mentioned. It is worth reading. The API names have all changed - for example, SEM_post() is now Semaphore_post(). Many times this is just a matter of find/replace. I recommend NOT using the switch to auto migrate DSP/BIOS to SYS/BIOS. Just go through each .c file, search/replace and rebuild in the new SYS/BIOS project. Again, do one thread at a time and build it in the SYS/BIOS environment to reduce mistakes. Regarding SW migration, my previous points on ASM vs C and how to migrate each piece still holds true. Others may have more specific answers.