Memory sharing between ARM and DSP.

Good Morning Ralph,

Saw your post and thought I'd chime in on your questions. I'm no pro but I've been doing a lot of

digging around and thought I'd mention some things I've come across that might spare you some

time.

Regarding 1):

     If you're using the EVM as a stepping stone for eventually using an actual DM816X (as opposed to a C6A816x)

     then some of the address space is indended for use by the CortexM3s which comprise the VPSS functionality.

     That address space (for reserved-multimedia use) falls within the 1 GB range but doesn't explain the 2 GB ram budget.

     If you try to spin a board using less than 1 GB ram (say 512M), I saw another post on the forums that indicates this

     might not work because the Ducatis/(CortexM3) require some of the address space beyond that and the current

     EZSDK (ti-ezsdk_dm816x-evm_5_01_01_80) does not currently allow for changing the fixed memory maps.

     At least that's my understanding.

Regarding 2:

     Our team wondered the same thing regarding CMEM. Last time we were on OMAPs we had to deal with

     a CMEM/DSPLINK combo. We haven't needed CMEM ourselves yet explicitly. SYSLINK has sufficed for

     now [we've just begun our evaluations] but the CMEM code (assuming your on the EZSDK) should be

     in ti-ezsdk_dm816x-evm_5_01_01_80/linuxutils_3_21_00_02_eng/packages/ti/sdo/linuxutils/cmem.

Hope this helps.

- Juan

Hi Juan,

thanks for the reply. I've spotted the cmem source code as well. It's good to know I'm not alone in my thoughts.

I just considered the memory allocation to be very tight on the Linux/CMEM side of things, especially given the advertised 3 x decode and 3 x encode 1080p60 capability of the board. It would be good to know how much memory the H264 stuff needs and maybe a bit more about how it is allocated. I am aware that it is the codec server's configuration that determines the memory allocation for the non-shared DSP algorithms but I find no H264-codec server stuff as there was with the DM6467T.

Update: I've read this thread: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/106189.aspx and I think I understand the ideology of why only 256MB was chosen, although I disagree with it given the first target audience of the EZSDK is those people who own EVMs (2GB of RAM universally, not 1GB as the EZSDK would imply).

I also know from the post above how to allocate more memory to Linux, but I am completely confused which memory map for the DM8168 DDR3 EVM I should be using with EZSDK 5.01.01.80 (the latest). Is it:

a) The one from the EZSDK FAQ on this website which would suggest that it is 256MB at the start for Linux and you can optionally have 256MB at the end of the block (plus an unknown 12MB which got lost in the diagram somewhere; the sum of the memory blocks only adds up to 1012MB).

b) The one in the EZSDK release notes which says Linux takes 256MB at the start of the 1GB block, and that's all it can take as the rest is allocated elsewhere or marked as "reserved".

:-S

Ralph

Hmm, in case it wasn't clear before, I would really like to know the answer to question 2) in my first post, and also which memory map is being used in EZSDK 5.01.01.80?

Many thanks,
Ralph

For answer 2)  ememk.ko can be found under ./c674x-dsplib_1_03_00_00/example/call_dsplib/linux/cmemk.ko

Hi thanks for your answer. I don't think I phrased my original question as clearly as I should have.

What I meant was, how is the cmemk module used now in the context of H264 decoding? When I do H264 decoding, I notice that it is no longer a requirement for me to load it before doing a decode. Before (with DM6467T) I had to allocate pools of memory for the DSP before the decode. Please could you explain the mechanism of memory allocation between DSP and ARM as I've read all the Wiki documents on changing the memory map but they no longer are applicable to DM8168 H264 codecs as they exist in EZSDK 5.01.01.80?

Thanks,
Ralph

Hi Ralph,

In DM8168, codec engine is not used on A8 / host , which requires cmem. So in EZSDK codecs there is no need for cmem. In SDK, there is a section reserved for all buffers for all components, which is managed by firmware. This section is shared memory section so other cores can access it. Address translation is taken care by syslink/domx.

Regards

Vimal

Hi Vimal,

wow, this is news to me but it makes sense with what I've seen in the EZSDK so far. I'm surprised that Codec Engine is not used to handle communications with the H264 codecs.

What is the maximum amount of memory used by the HDVICPs when decoding/encoding* 3 separate _high_ profile H264 streams? We are currently making a big decision on how much memory our system needs so the answer to this question would be particularly useful. I am aware of the publication of the memory map in the current EZSDK however I am also aware that in practise forum users on both sides of the TI/community fence have been having trouble getting dual decode to work so I would prefer an answer from the people who know for certain what the memory requirements are for this "worst case scenario".

While I'm here, how does the OpenMAX framework talk to the codecs? Presumably it uses Syslink but could you point me to the header files that describe this communication at the Syslink layer? Is the communication done via the media controller?

Thanks very much,

Ralph

*whichever of the 2 has greatest memory use

Ralph,

I meant codec engine is not used from A8 side, i.e. there is no direct communication to H264 from A8 by codec engine. It is done by OpenMax apis on A8, which  gets translated to mediacontroller by DOMX. DOMX has proxy and RPC calls, similar to codec engine, which passes the OMX APIs to MediaController.

Memory requirement of codec depends upon profile/resolution/level, number of reference buffers. For example H264 decoder 4.1 highprofile for 1920x1080, would require ~9 o/p buffers. (If stream has lesser number of referance buffers, it will require lesser)  each buffer after alignment and padding requirement would be of ~3.5 MB, so o/p buffer requirement of typical H264 decode would be around ~31 MB. besides o/p buffer, each instace of decode would take internally ~9 MB. and assuming 4 input buffers of 2MB input buffer requirement  would be 8 MB, so total for one instance of decoder ~ 31+9+8 == 48MB approx will be the raw memory requirement. For system level requirement, it would depend whal all components you would use for your use case.

Dual decode issue is not beacuse of memory constraint. initial investigation points to some issue with sdk component.

Regards

Vimal

Hi Vimal,

thanks for your reassurance once again. I was wondering about memory again as I know the memory map at present reserves ~650MB for the video decoding which seems an awful lot more than the 30MB per decode/encode that you speak of (and I also saw this figure in some old HDVICP codec datasheets)

I think I'm slowly understanding how the whole system works and the difference in controlling a DSP codec (->codec engine) and controlling a HDVICP codec (->DOMX). I thought I had read all the documentation and don't think I saw anything about DOMX. Are there any documents available on how this works?

Thanks,
Ralph