• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 81 subscribers
  • Views 198 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: Question concerning the comunication/ shared Data between CLA and CPU

Wilko Moritz
Prodigy 95 points
Part Number: TMS320F28388D
Greetings,

I have a question regarding the shared variables used in both my CPU and CLA code.

I define these shared variables in a header file, which is included in both my CPU and CLA files. However,  there is a discrepancy in how pointers are interpreted between the CPU and the CLA.

The CLA interprets pointers as 16 bits, whereas the CPU interprets them as 22 bits. This has led me to consider padding the pointers used by both the CPU and the CLA.

My main query is whether I need to pad every pointer that is shared between the CPU and the CLA?


Furthermore, the CLA interprets variables as 32 bits and does not recognize 16-bit variables. Does this mean that every variable shared between the CLA and the CPU needs to be at least 32 bits in size?

Lastly, I would appreciate clarification on whether the datatype size_t can be safely used on the CLA. My understanding is that the CPU interprets size_t as 16 bits, whereas the CLA interprets it as 32 bits.

Thank you for your assistance.

Regards,

Wilko

  • 0
    TI__Expert 6760 points

    Hi Wilko,

    Where in the CPU/CLA shared memory are you placing these variables? In the CPU to CLA MSGRAM or in the CLA to CPU MSGRAM?

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 95 points

    Hi Delaney,

    we have united the RAMLS0 and the RAMLS1 and called this memory CLA_CPU_SHARED. For that we have set the "MSEL_LSx" to "01" and the "CLAPGM_LSx" to "0".

    We use this for data, that both CPU and CLA need to read and write to.

    The CPUToCla1MsgRam is used for data the CLA only needs to read.

    Maybe it helps, if I try to further clarify the information I am uncertain about.

    https://software-dl.ti.com/C2000/docs/cla_software_dev_guide/faq.html#how-is-data-shared-between-the-cla-and-c28x
    In the above mentioned link under 4.6 it is described how data types are different between the CPU and the CLA.

    The link mentions that pointers need to be padded as described in my original post. This padding  I am asuming needs to be done for ervery pointer, that is shared between CLA and CPU.

    The second part described in 4.6 is the size of data types. In my understanding the CLA only uses 32 Bit Data types.

    But reading this article I am unsure if I can have a uint16_t variable in my shared memory. Does the CLA "understand", that the variable has only half the size ?

    My uncertanty with size_t is quite similar. I have a function "doublebuffer" that called by the CPU aswell as the CLA and I am uncertain if the size_t is interpreted correctly.

    Best Regards,

    Wilko

  • 0 in reply to Wilko Moritz
    Prodigy 95 points

    P.S. I just found the following : "CLA code cannot call C28x functions" in

    http://downloads.ti.com/docs/esd/SPRU514/#viewer?document=%257B%2522href%2522%253A%2522%252Fdocs%252Fesd%252FSPRU514%2522%257D&url=c-language-restrictions-spru5144314.html%23SPRU5144314

    Does this mean I cant use the same function in the CLA and the CPU ?

  • +1 in reply to Wilko Moritz
    TI__Expert 6760 points

    Hi Wilko,

    I see, thank you for clarifying. Here are the answers to your questions:

    • Correct, for every pointer that needs to be used/understood to reference the same address by both the CPU and the CLA, this padding would need to be done. You can use the CLA_FPTR union you made to define all of these pointers.
    • While the CLA architecture is designed for 32-bit variables, it can still "recognize" 16-bit variables in memory. When a uint16_t variable is compiled for the CLA for example, it is converted to an unsigned short in the C standard language, which is stored as 16-bits in the memory physically. These typedef conversions can be seen in the stdint.h file in the code inside the #if defined(__TMS320C28XX_CLA__) [shown below]. It is saying that if the compiler is compiling for the CLA, a unit16_t variable in the source code gets translated to an unsigned short type in C, whereas it would be translated to an unsigned int if compiling for the c28x.
    • When the CLA does computations with this variable, the processor has to sign extend the 16 bits of data to 32 bits, which incurs some extra overhead (as opposed to storing the variable in 32 bits of memory, where no sign extend would be needed.) So yes, the CLA would understand that this variable is only referring to 16 bits in memory and you should see no issues with using a uint16_t. 
    • Similarly, if you look at the stddef.h file to see where the size_t typedef is defined, you can see that there is no separate definition depending on if the code is being compiled for the CLA vs. the c28x, meaning that it would have the same meaning on both processors.
    • Functions (with the same name) can be shared between and used by the CLA and c28x as long as they are inline functions and placed in your CLA_CPU_SHARED memory. For inline functions, the compiler will replace the function calls in both the CLA and c28x source code directly with the function contents, so no function name would actually be used, which is why this wouldn't cause any sort of conflict.

    Let me know if you have any more questions. Another resource that would be useful to take a look at is the TMS320C28x Optimizing C/C++ Compiler v22.6.0.LTS User's Guide (Rev. Z) if you want some more information.

    Best Regards,

    Delaney