Access CMEM from the DSP on DM6446

Hi BMillikan,

(I suppose that you use EVM6446.)

I think if you want to access CMEM memory from DSP side,

1. First of all you should let DSP jump out from "reset" state.

2. To find a way to tell DSP that where DSP can find the pointer of contiguous memory allocated from ARM app.

I think you can write a codec (XDAIS complince) in DSP side, and then call "process" function, you can find the configuous memory pointer among the parameters.

For example:

VIDENC:

XDAS_Int32 VIDENCCOPY_TI_process(IVIDENC_Handle h, XDM_BufDesc *inBufs,
    XDM_BufDesc *outBufs, IVIDENC_InArgs *inargs, IVIDENC_OutArgs *outargs);

"inBufs->bufs[index]" is the answer.

Hi Lorry,

If I'm not using the codecs, how would I use it?

Thanks,

Brian

Sorry BMillikan, I don't know how to answer your question as my experience. I think TI experts can help you to reply it.

[edit] I think  in relation between ARM and DSP, DSP is always passive, so if you don't want to use codec interface to pass the pointer of contiguous memory to DSP, you should use another way to simulate the way of codec interface to do it except that there is another way to pass the pointer. 

For the most part all of the CMEM accesses are abstracted by higher level software, namely Codec Engine, you can still use Codec Engine even if you are not using a true codec, in particular you may want to look at this wiki article on IUNIVERSAL. If you leverage Codec Engine than you will be using CMEM underneath, unfortunately I do not know of any collateral on using CMEM directly, I suppose you could pass the pointers as you initially mentioned for starters.

On the 644x, the DSP doesn't have an MMU (like on OMAP), so passing these buffers to the DSP should simply require 1) getting the physical address from CMEM (the DSP uses physical addresses), and 2) passing that address (and perhaps the buffer's size) to your DSP app - perhaps via DSP Link's MSGQ.

The DSP side can then read/write that memory.  Ultimately, because CMEM allocated the buffer, it will have to free it, so transferring ownership of the buffer back to the ARM must also be considered.

Finally, be careful about DSP-side cache coherency - it's not trivial.  There are some articles about this here:

http://tiexpressdsp.com/index.php?title=Cache_Management

Chris

It just seems like a lot of code overhead since we're not using any of the codecs.  We have to write our own.  Maybe I'm wrong, but the codec engine doesn't seem to buy us anything.  I've got the dsplink to work.  It just seems more straighforward to use that and our ARM application is already using CMEM buffers to operate on the data, so why not just pass pointers to those buffers to the dsp through dsplink and use our own codec?

It's true that you don't need Codec Engine for the simple use case you're describing.  Using DSP Link and CMEM should suffice.

However, there are some nice features that Codec Engine takes care of for you as your SW stack grows... things like:

• Buffer address translation
• Efficient cache management
• Detailed tracing support - including pulling DSP-side tracing off the DSP core and displaying it
• Dynamic task create/delete (via "codecs") instigated from an ARM application
• Resource sharing (e.g. Memory, DMA, HW accelerators, etc) between "codecs" from multiple vendors
• Currently supports OMAP, DaVinci, multi-core and single-core (both ARM-only and DSP-only), and includes a roadmap for future devices and ARM-side Operating Systems like WinCE

I'll stop there.  For simple applications, you're definitely right - using Codec Engine is a big hammer.  But if you see your system growing up to need some of these more complex features, it may be worth considering using the features in Codec Engine rather than inventing them yourself.

Up to you, of course - we support a stackable architecture... you can use just CMEM and Link and grow as you need to.  We just want you to be successful so you can buy more TI silicon!  ;)

Chris