Migration from for C6416 to C6657 (DSP/BIOS - SYS/BIOS changes?)

Hi Nasos Pap,

I believe the product that will help you is called the "BIOS Multi Core SDK" (MCSDK).

Please see this link for a release that supports the 6657 as well as some more info.

As far as migrating from a DSP/BIOS app to a SYS/BIOS app, yes, the legacy migration guide that you found is your best bet.  I would recommend going through that and using that document to help guide you in migrating your existing BIOS 5.x app to work with BIOS 6.x.  Please note that DSP/BIOS legacy support is being phased out in the latest versions of SYS/BIOS, but you should be OK with the SYS/BIOS version that was shipped with the BIOS MCSDK I linked above.

I also saw this related thread regarding porting of CSL ... not sure if you will need to do that but thought I'd list it since I came across it.

Steve

Hi,

thank you for your reply! 

Unfortunately,  as I found out this migration guide is not suitable for my project:  it is not possible to migrate a c6416 DSP/BIOS project to SYS/BIOS since c6416 is not supported by SYS/BIOS! 

Indeed,  when I followed the instructions, I got the error "Target no longer supported"

Nasos Pap said:

Unfortunately,  as I found out this migration guide is not suitable for my project:  it is not possible to migrate a c6416 DSP/BIOS project to SYS/BIOS since c6416 is not supported by SYS/BIOS! 

Yes, this is true.  But your use case is slightly different.  I think you need to do a combination of the following at the same time:

1. migrate your C6416 app from DSP/BIOS to SYS/BIOS

2. port your C6416 app to C6657

Assuming you've done #1 already, then for #2, can you try changing the hardware platform in the build options of your project to use your 6657 board?

Steve

I posted this on the other forum and made a copy here. FYI - Steven is a great resource and can offer more details than I provide here, but wanted to document my response in both places for clarity - 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.

Thank you, Eric!

You gave an analytic and very helpful description of the process.

The Idea that came up from your analysis is this: we also have the project already built (with some application differences) for C6748. We will investigate the idea to port the C6748 project from DSP/BIOS to SYS/BIOS, change to C6657 DSP and then integrate the C6416 functionality to the new project.

Glad to help. The key thing is "one thing at a time". The more you try to do at once - the more Advil you will need.  ;-)  Good for the drug companies - bad for you.  

Good luck with your porting challenge !