• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1050 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DDR3 as Shared memory

Javier Eroles
Intellectual 430 points

Hi everyone,

I am using the C6657L evaluation board and I am implementing an application that runs in both cores in a sequential way (when the first one finishes the second one starts, and so on). The output from the first one (bufA) should be the input to the second one, but for now i just print the content of bufA from the task running on Core1.

As a first approach I was thinking in using global variables stored in the DDR3 memory. I attach the .c code of both tasks in on file (I sburn them separately in the two cores).

I am using as a baseline the example of Notify for the IPC mechanism. In both notify cores I write this line as well:

notify_multicore.cfg

Program.sectMap[".PingPongBuffer"] = "DDR3";

I have seveal questions:

  • From the Memory Browser I see that bufA is stored in 0x80000000 which is the base address for the DDR3, but I also see that this buffer is highlighted in blue, which means that it belongs to L1D Cache. Is or is not in DDR3?
  • I also see that the result I see printed on console doesnt correspond to the memory browser. 
I am not quite sure that I am sharing correctly this variable. I just want to allocate some static memory for sharing data from one core to the other. 
Thanks in advance
  • 0
    Expert 2430 points

    Hi,

    From the Memory Browser I see that bufA is stored in 0x80000000 which is the base address for the DDR3, but I also see that this buffer is highlighted in blue, which means that it belongs to L1D Cache. Is or is not in DDR3?


    Both ;)
    When accessing shared memory such as DDR through a cache, you need to make sure to execute:

    • a writeback on the core which modified it, using Cache_wb
    • an invalidate on the core reading the data so it does not see stale data, using Cache_inv

    So it seems you placed the memory the right way, you are just tricked by caching effects.

    Regards, Clemens

  • 0 in reply to Clemens Eisserer
    Intellectual 430 points

    Thanks Clemens, but the first trial didnt work.

    I change a bit the code to understand better what it is happening. Now, core 0 is writing once in the buffer, then send the notification to core 1, core 1 read the buffer from DDR3. This is done correctly. After that when I repeat the execution writing a different content in the same buffer in DDR3 and send a notify to core1, core 1 shows again the same content of the buffer as the first execution.

    My conclusion from that is the problem is related to the Cache (the core 1 is reading an old copy of the buffer) but I dont know what I still am doing wrong (I am enabling cache and I am writing back in core 0 and invalidating in core 1). Do I need to change anything in the configuration file? Is there any example of how to use cache with this platform?

    Thanks in advance again.

  • 0 in reply to Javier Eroles
    Intellectual 430 points

    Breaking news. I fixed it by disable complete the caching of DDR3.

  • 0 in reply to Javier Eroles
    Expert 2430 points

    > Breaking news. I fixed it by disable complete the caching of DDR3.

    Which is an even stronger sign you didn't do cache-wb and cache-inv properly before ;)

  • 0 in reply to Clemens Eisserer
    Intellectual 430 points

    You are right. I dont know how to do it and where I am missing something

    It seems that the Cache is enabled by default (otherwise if I dont disable it the execution fails).

    In addition I dont understand quite while the variable appears in L1D according to the Memory Browser if I am not initialising this memory (all the variables go to L2SRAM, which is not cacheable by default). If the variable is used many times the core transport it to L1D?

    I really want to understand why I am not using correctly the Cache.

    Thanks Clemens!

  • 0 in reply to Javier Eroles
    Expert 2430 points

    Hi,


    It seems that the Cache is enabled by default (otherwise if I dont disable it the execution fails)
    In addition I dont understand quite while the variable appears in L1D according to the Memory Browser if I am not initialising this memory (all the variables go to L2SRAM, which is not cacheable by default). If the variable is used many times the core transport it to L1D?

    Yes, by default L1D and L1P is configured as cache, so not directly adressable but instead used to buffer reads and writes from/to slower memory regions. L2SRAM (~10-15 cycles access latency) is usually also cached by L1D (~2 cycles best case latency).

    If you have time, there is the "TMS320C66x DSP Cache User Guide" (SPRUGY8) document- which might not seem immediatly useful but will for sure provide insights what is going on behind the scenes.

    Regards, Clemens