Can I build my own algorithm on DM6446?

Developing the DSP algorithm via CCS and building lib file is actually the hard part.  After that you need to ensure that your DSP algorithm is XDAIS compliant; FYI, XDAIS is a standard which ensures algorithms created by diffenrent vendors play nice together; as you may guess, in order to ensure this, XDAIS algorithms need to follow certain rules such as asking for resources such as memory, instead of just taking it.  After you have you XDAIS algorithm, you can add another thin wrapper to make your algorithm XDM compliant (superset of XDAIS); codec engine software framework works with XDM compliant algorithms.

The following XDAIS documentation may help: http://tiexpressdsp.com/wiki/index.php?title=XDAIS_Documentation

Also, if you have not done so already, I would suggest you get your free copy of the following book which will give you a good overview of the software architecture (including pieces described above): http://community.ti.com/forums/t/2523.aspx

Dear Sir:

Thanks for you applying.

I've found some resource in TI internet.

I found a file named 「Codec Engine Algorithm Creator User’s Guide」and it's numbered as sprued6c.pdf.

In this file, it mentions that to create a new API by user, we have to use "VISA_create" function.

I think this might be an useful file.

So I want to make sure that if this file is useful for me to design my own library and add lots of APIs except process, control,init...

Thank you very much.

Yes, this it the correct document if you want to write your own algorithm and have it work under the codec engine framework.

Dear Sir:

When I check the "algorithm creator" document, I found an example "Scale".

I think this is an useful example if I want to develop my own algorithm.

But I still have some questions:

1. Scale only have 4 functions in it. SCALE_create, SCALE_delete are essential, how about SCALE_process and SCALE_control?

Are these two functions essential?

I want to build my own image process library in DM6446, like watershed, color converter and can be accessed from ARM side so  I'd like to make sure if my ideas are right.

(1). I need to add more functions in my stub.c file, and function table (just like process and control function do).

(2).  I should add more mappings in the function "call".

(3). Modify package file in the DVEVM example. after (1) (2)(3) the algorithm may work.

(4). I can use "malloc" in DSP library but should under CMEM mechanism.

Thanks for your adivce.

Penny

Penny,

create, control, process and delete are key functions.  Normally during setup stage, you call on create (creates algorithm isntance) and control (to configure algorithm).  Then, during processing state (e.g. video decode) you call on 'process' function.  Finally, during cleanup stage you call 'delete' function.  Rather than adding new functions, the 'control' function is a good place to add functionality; sort of having your standard ioctl call in Linux used to send all IOTCL requests.

Also, with regards to CMEM, it makes the process of passing large amounts of memory between ARM and DSP efficient.  You do not have to use it for passing small size data (do that via data-structures in calls such as 'process'), or to allocate memory that is only going to be used by DSP side.

FWIW, recent releases of Codec Engine and XDAIS include support for IUNIVERSAL.  The good news is that this may allow you to avoid creating your own API with stubs and skeletons - which is likely an easier approach.  There are more details here:

http://wiki.davincidsp.com/index.php?title=Getting_started_with_IUNIVERSAL

The bad(?) news may be that this support is only available in CE 2.2x and later, which require Monta Vista 5 and its toolchain.

Chris

Juan Gonzales said:

Developing the DSP algorithm via CCS and building lib file is actually the hard part.  After that you need to ensure that your DSP algorithm is XDAIS compliant; FYI, XDAIS is a standard which ensures algorithms created by diffenrent vendors play nice together; as you may guess, in order to ensure this, XDAIS algorithms need to follow certain rules such as asking for resources such as memory, instead of just taking it.  After you have you XDAIS algorithm, you can add another thin wrapper to make your algorithm XDM compliant (superset of XDAIS); codec engine software framework works with XDM compliant algorithms.

The following XDAIS documentation may help: http://tiexpressdsp.com/wiki/index.php?title=XDAIS_Documentation

Also, if you have not done so already, I would suggest you get your free copy of the following book which will give you a good overview of the software architecture (including pieces described above): http://community.ti.com/forums/t/2523.aspx

 

Hi Juan,

I have developed DSP algorithm via CCS and I am Using DSP Bios ( DM6446 evm). I have the following questions:

1. With regard to this reply, which lib file needs building?

2. I would like to  port the DSP algorithm to Codec Engine. I have been following this document  http://wiki.davincidsp.com/index.php?title=Porting_GPP_code_to_DSP_and_Codec_Engine , The document suggests to make the code XDAIS/XDM compliant.  Is this step necessary? Will my DSP algorithm work in Codec Engine without this?

3. During compliance test using QualiTI XDAIS Compliance Tool, I see .l64p library loaded. Which step or how do I create this Library?

4. After XDAIS/XDM compliance test, the next step suggested is to Create RTSC package and Unit Server for Codec Engine. This step uses an  XDM  Compliant library. Is this Library the same as .l64p created during the steps above?  if not How do I create this library?

5. I have installed the wizard in windows to Create RTSC package and Unit Server for Codec Engine as explained in this document http://wiki.davincidsp.com/images/2/24/Wizard_instructions.pdf , which mentioned I also need a Codec engine for the wizard to work.  I have copied the codec engine I am using from linux to windows to enable the wizard to run correctly. is this o.k? I just need to make sure as this is not mentioned in the document  although the wizard is now running.

6. When following the steps to use the RTSC codec package wizard, step 2 asks for library information. what are the main libraries required in this step? Do they include the .l64p above?

7. Once the Codec package, server package, DSP executable created.  The next step is to test them under linux as suggested in http://wiki.davincidsp.com/index.php?title=Porting_GPP_code_to_DSP_and_Codec_Engine#Step_7_:_Test_the_package.2C_server_with_DMAI_GPP_sample_app_and_DVTB

At this point Do I just copy these packages and executables and move them from windos to Linux ? so that the  algorithm can be invoked from a Linux  application using Codec Engine and running on the ARM?

I am sorry for a long list of questions. I am a newbie and I would like to learn this step by step.

Jonners

Jonners,

I am not an expert in all these fields but will do my best to answer all your questions.  Also, at the bottom of all wiki articles such as http://tiexpressdsp.com/index.php?title=Porting_GPP_code_to_DSP_and_Codec_Engine you referenced above, there is a 'Leave a comment' link; I would encourage you to provide feedback on how the article could be improved via this link; specially if there are gaps in the information flow or something is unclear.

To answer your questions

1) Please note that in the DSP side, only one DSP image (or executable) can be running at any one time.  Therefore, most algorithms are deveoped and built as libraries (l64p or a64p files); eventually all dsp algorithm libraries are pulled in into a single dsp image (x64P file also known as codec engive server, dsp server, codec server..), which includes the codec engine framework.  Plase keep in mind that this is looking at it from a DSP perspective, you can have algorithms and servers on the ARM side as well hence the reason for using names other than the simpler DSP image.  So to answer you question about which lib file needs building?  That would be your dsp algorithm.

2)  In order for you algorithm to work within the codec engine framework, your algorithm needs to be XDAIS/XDM compliant. 

3) So this is an area where I would request clarification on the wiki article.  My best guess is that you can just rename the lib file produced by CCS to l64p, but I have not done this before so we definitely need more clarification here.

4) yes and no; this really depends on the developer; as a developer, it would be really easy to develop a DSP library, but it does not guarantee it is XDM compliant; there are rules you must follow to ensure it is XDM compliant.  I guess whant I am trying to say is that you first need to make sure that you algorithm is XDAIS compliant, then extend algorithm to be XDM compliant as well.  I believe the wiki article http://tiexpressdsp.com/index.php?title=Porting_GPP_code_to_DSP_and_Codec_Engine touches on this topics and has references to additional collateral (e.g. XDAIS wizards and compliance tools).  If are developing your algorithm to fit into the codec engine framework, than it needs to be XDAIS.XDM compliant; if you have done this per the XDAIS.XDM specifications, then in this step you would point to that library.

5) Yes, that is the way to use it.

6) In the codec package wizard, this would be your DSP algorithm (or library) for which you wish to generate RSTC packages.  Please note that you need RTSC packaging for both codecs (DSP libraries) and server (DSP image) and hence there is a corresponding server package wizard.

7) Actually, I think you move everything (libs and RTSC packaging) to Linux where you build the actual DSP image, although I do not see why you could not do this on the Windows side as well (so long as all the software components such as codec engine are the same).

Hi Juan,

Thank you very much for taking your time and for providing a very detailed answers. This will help me a lot. I will keep you posted on the progress.

Cheers.

Jonners

Dear Penny:

I am a new user of DM6467, and now I want to develop some algorithms such as a color converter, but I encounterd the same problem like you.

could you help me?

Thank you for your advice.

zhiqiangli