Multi-core programming in C6472 using shared memory

I want to build multicore application in C6472 using the shared memory. I am using CCS v4 as the compiler. I have read the document SPRUEG5C. The arbitration logic seems to be quite complex to me. In this regard I have some questions (I'm sorry for posting them if they appear silly) .

1. Does using optimization level-3 in CCSV4 imply that the shared memory access is configured to be pre-fetchable always? In that case I think I cannot use atomic access monitor in optimization level-3. Because SPRUEG5C says "Atomic access should go only to non-prefetchable address spaces." Am I correct?

2. Other than the configuration of prefetchable/nonprefetchable part of the shared memory, the power down issues and the fault indications, do I need to use the SMC memory mapped registers manually from my code or they will be used by the arbitration logic hardware only?

3. Reading the document for SMC controller it seems to me that the user 'talks' to the atomic access monitor and the atomic access monitor controls the arbitration logic hardware. The user cannot directly control the arbitration logic hardware without using atomic access monitor. Am I right?

4. While programming do I need to specify somehow the per-bank SMC controller through which I am trying to access the shared memory or the location of the shared memory I'm trying to access itself indicates the hardware about the per-bank controller through which the request should go?

5. From the C code if I want to access a shared memory location by a declaration like "#define VALUE (*((volatile unsigned int *) 0x00200000))" and then "VALUE=0x1234", when this code is compiled will it automatically pass the write(or read) request through the atomic access monitor (by using LL, SL, CMTL instructions in assembly) or I have to take some other step to ensure atomic access? If so then what are such steps?

6. Can anyone please send me an example project where shared memory is used by multiple cores preferably without using DSP-BIOS?

19 Replies

As per my understanding (developed by reading and discussion in this thread) the user
'talks' to the atomic access monitor and the atomic access monitor
controls the arbitration logic hardware. The user cannot directly
control the arbitration logic hardware without using atomic access
monitor. In my application more than one cores were trying to read a location simultaneously but that was not a write attempt. So I could bypass the requirement of atomicity. I used the shared memory location as a simple memory mapped register and that worked. If not mentioned, the code generation tool will not generate LL, SL, CMTL instructions (such as in my case I did not want atomicity, so SL2 access was using simple load store instructions). Also the post by Shreyas Prasad helped me understand the interleaved memory structure which is helpful for VLIW architecture. For large chunk of data (~2000) I checked the time required to write this chunk by different cores to different non intersecting regions in SL2. The overall time is almost same for simultaneous try of 1,2,3,4 cores. For more cores this time increases. This re-ensures the 4-bank structure.

But as per my understanding harping on the same string as one and zero, if DSP BIOS is to be avoided then the only way to ensure atomicity is to use LL, SL, CMTL. Now next question comes whether to embed these assembly codes inside C code using 'asm'? I was advised in forum not to do so. Because for doing that I need other registers also. But don't know whether the cross compiled C code is doing something with that register or not. So there comes question of push pop into stack or else knowing the way the registers are handled by the code gen. tools. Things will be complicated. So I think writing functions using these assembly instructions and calling them from C code in order to maintain atomicity will be a better option. Though in that case also there are some restrictions on the register usage (can be found in 'optimizing compiler' doc) still I think (not tried) that will be a simple way.

Wow! I really can't believe that things can be so complicated for something so simple. Atomicity is certainly much simpler with a hardware semaphore like the C6474...

Have the TI developers considered developing a CSL API that would make this process a little simpler, and perhaps include in a new release of the CSL?

Ok, so before I spend a few weeks attempting to get this working the way you suggest, I would like to know:

Is there perhaps another way of developing a semaphore that guarantees atomicity towards common resources for the C6472? I'll have you know that I have studied all the available documents on the TI website that address this, but to me, none of them seem as sound and reliable as a hardware solution.

Which 'examples' are you referring to before, and where exactly can I get hold of them?

Ok, so based on the examples in the documentation you suggested, I have attempted a very simple approach and it seems I am stumbling at the very first hurdle. Here is the simple C code for my main routine:

#include <stdio.h>

extern asmfunc(void);

void main(void)

{

asmfunc();

}

And here is the simple assembly function (.asm file) I created, and simply included into my CCS 4.0 project:

"../asmfunc.asm", ERROR! at line 4: [E0004] Memory operand must be B side register LL *A8, A6 ;load linked (lock) and store in A6

"../asmfunc.asm", ERROR! at line 7: [E0004] Memory operand must be B side register SL A6, *A8 ;new value to store back

"../asmfunc.asm", ERROR! at line 8: [E0004] Memory operand must be B side register CMTL *A8, A1 ;commit the store

I naively attempted to change all the A registers to B registers, which seems to compile. However, the function simply hangs up during execution, and according to Table 7-2 (SPRU187Q) these changes does not make sense in any case..

You need to be very careful when using registers in Assembly called from C. When you call asmfunc and pass the address of gvar the compiler and assembler have an agreement as to what register the address of gvar is going to be stored in. You can't just switch all of the registers to B registers and hope for this to work, because the Compiler is still going to store the gvar address value in the same location. From the looks of this code, the assembly routing expects the address of gvar to be in register A8. Whether or not this is the correct register, I am not sure. Check the Compiler Guide for the parameter passing conventions or debug this on a Simulator or hardware and look at the assembly instructions generated by the compiler in Main just before calling asmfunc and see where the address of A8 is being stored.

Regarding the errors that you are getting from the assembler, you also need to be familiar with the Instructions that you are using. See the C64x+ Cpu Instruction Set Users Guide for details on the available instructions for the 6472 (I believe you referenced this document.) When you look at the LL instruction, it specifies that it needs to use the .D2 unit. This unit gets it's operand from the B register file. So, one of the operands must be in a B register. I _think_ it's the pointer value, but I'm not 100% sure. Again, it never hurts to try this, compile it, and then step through and debug it to see if the registers get updated as expected.

Please Create New Threads for New Issues, and even for similar issues that have already been reported. Do not reply to a thread that has already been answered and say "I'm having the same problem". You will get a faster response if you create a new issue that is not already marked answered.

-----------------------------------

Don't forget to verify answers to
your forum questions by using the green
"Verify Answer"
button.

Did you read the CCS
Forum Guidelines & FAQ? If not,
PLEASE read it. If you haven't read it in awhile, please read it again
to see if any updates were made.

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.