How can I get contiguous memory on DSP side under DM6446?

This depends on what context you want to allocate contiguous memory in, if you mean to do so from within a codec (XDM compliant algorighm) than you would use memtab as discussed in the XDM/XDAIS documentation so that the application can allocate for you. If you mean in a general sense on a C64x+ executable than you could just allocate a large array or use MEM_alloc/malloc to obtain the memory. The C64x+ on the DM644x does not have a MMU, so all addresses used by the C64x+ are physical addresses, therefore when you allocate an array or a memory area from malloc it will be contiguous.

Bernie Thompson, thank you very much for your reply. Now I understood about how to get the contiguous memory a little. My problem is get contiguous memory within my codec. The resources you privided are very rich, but could you tell me which paper I should read? Cause I don't have enough time to read all of the papers you recommend. If you could provide me some or an examples(like source code), I think that's very helpful to me. Thanks again.

Since you mentioned DM6446, you probrably do not want to take advantage of codec engine and not re-invent your own software framework for ARM-DSP communication.  If this is the case, then codec engine requires all DSP algorithms be XDM (layer above XDAIS) compliant, hence you will want to use memtab.

FYI, there are some sample codecs (or DSP algorithm) source code under codec_engine_xx_xx_xx/examples directory that you may be able to use as reference code.

Hi, Juan. Thanks for you reply. I exactly want to take advantage of the codec engine. But I just don't know how to make it. I want to implement two frames difference in my codec(just an example), so I have to alloc two pieces of memory to realize frameA minus frameB. In my codec, can I just use malloc function to apply for the two pieces of memory?

The examples you offered were not refer to my question(they just copy the input buffer to the output buffer), but I should thank you all the same.

Are you passing these frames  between ARM and DSP, if so memTab is probrably not the right place.  CMEM (Contigous memory allocator) is shared memory space between ARM and DSP and is the best way to send large buffers back and forth (you only pass the pointer).  I am not too familiar with memTab, but I believe this is used primarily for memory that is needed by DSP-only (not visible to ARM).  If you are indeed interested in memory buffers that are specific to DSP, then we can look into this for you, but it will probrably not be using malloc functions.  The whole concept around XDAIS (required by codec engine framework) is that DSP algorithms do not grab memory on their own but request memory from the framwork; this is what allows algorithms written by different teams or vendors to co-exist.

Hi, Juan. I'm not passing the frame between ARM and DSP. I knew that CMEM is the right place to share by ARM and DSP. As you mention, I want the memory just for DSP-only. Cause in my codec, I need some interim memory to hold my result. Just like you said, I'm indeed interested in memory buffers that are specific to DSP. I don't have a clear concept of memory alloc.

Last night, I did a test in myvidenc code(provide by IT's workshop, in lab14b), I modified some source code like this:

(the function MYVIDENC_TTO_process in myvidenc.c):

//my target is get a buffer from DSP's memory to hold the input buffer, and then copy the interim buffer to the output buffer(very silly test)

XDM_BufDesc *frame = (XDM_BufDesc *)malloc(sizeof(XDM_BufDesc));

//ignore some code
...

//In the for loop, I use the interim buffer:

memcpy(frame->bufs[curBuf], inBuf->bufs[curBuf], minSamples);//copy the input buffer to the interim buffer
memcpy(outBufs->bufs[curBuf], frame->bufs[curBuf], minSamples);//and copy the interim buffer to the output buffer

(the function MYVIDENC_TTO_alloc in myvidenc.c):
memTab[1].size = sizeof(XDM_BufDesc);
memTab[1].alignment = 0;
memTab[1].space = IALG_EXTERNAL;
memTab[1].attrs = IALG_PERSIST;

return (2);

OK, finish the modification, compile and run. But the output(screen) was a mess. I suspect that the buffer maybe not alloc correctly, is it?

lukysuper@163.com said:

OK, finish the modification, compile and run. But the output(screen) was a mess. I suspect that the buffer maybe not alloc correctly, is it?

If the allocation was not correct I would have expected more of a crash or no output at all, a messed up output sounds like something else may be going on, my first suspcion being a caching issue which I have seen manifest itself as portions of lines of the image not being what you would expect and flickering around. Essentially the caching issue (cache coherency) would be because the cache on the C64x+ is not guaranteed to write back to external memory immediately so a memcpy may not make it into external memory until the cache is given a writeback command or the cache lines are otherwise evicted, this is a problem if you are depending on video port hardware to display something directly out of memory since it cannot see into the C64x+ cache. Essentially you want to perform a cache write back after your codec has finished and a cache invalidate before you read in a new buffer. Of course this may not apply here, with the codec engine framework and CMEM I believe the cache coherency of the input and output buffers is already being managed so this could be something else going on within your program.