• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 84 subscribers
  • Views 1245 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.

TMS320F28075: Arbitration Scheme on Local Shared Memories

Pierre Bouchet1
Expert 2595 points

Part Number: TMS320F28075
Other Parts Discussed in Thread: TMS320F28035

Hello everyone,

I would like to understand the consequences of the arbitration scheme on LSRAM described in Figure 2-15 of the TMS320F2807x Technical Reference Manual.

Let's assume the CLA tries to read an address at the exact same cycle the CPU writes to that address. Does the existence of round-robin arbitration imply that, depending on the previous round-robin state, the CLA Read might be stalled for one cycle waiting for the CPU Write to go through?

Regards,

Pierre

  • 0
    TI__Guru** 116081 points

    Hi,

    Does the existence of round-robin arbitration imply that, depending on the previous round-robin state, the CLA Read might be stalled for one cycle waiting for the CPU Write to go through?

    That is correct. It could also happen that CPU write get stalled due to CLA read. It all depends on round-robin state.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Expert 2595 points
    Vivek,

    Does this occur only if the CPU and the CLA both try to access the exact same address or does the round-robin apply whenever they both try to access the same LSRAM area regardless of the target address?

    Cheers,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru** 116081 points
    Pierre,

    Arbitration/stall happens when both try to access same LSRAM block (even different address with-in same block).

    Vivek Singh
  • 0 in reply to Vivek Singh
    Expert 2595 points
    Vivek,

    Thanks for the information. Is it different with the CLA to CPU and CPU to CLA message RAMs? I mean the ones at 0x1480 and 0x1500. Can they cause delays in the CLA execution?

    Cheers,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru** 116081 points
    Arbitration scheme is same but message RAMs are for data only.
  • 0 in reply to Vivek Singh
    Expert 2595 points

    Vivek,

    Two more questions:

    • Was this already the case with previous ePWM types such as the one on TMS320F28035?
    • This round-robin arbitration is very troublesome. For example it means that I cannot use the CPU to update the setpoint of a CLA control loop without the risk of delaying the control loop. Therefore the deterministic aspect of CLA execution, which was always one of its major advantages, is much more difficult to ensure. Are there any workarounds or additional features which can help mitigate this issue?

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru** 116081 points
    Hi,

    I am not clear on your query about ePWM types. We did not discuss ePWM in this post.

    On arbitration, the stall is only for one access so that should not cause big delay in control loop. Also this is only when reading the data. For CLA code execution, LSxRAM are dedicated hence no issue there.

    Vivek Singh
  • 0 in reply to Vivek Singh
    Expert 2595 points
    Vivek,

    My bad, I got mixed between peripheral names. My question was whether the arbitration scheme was the same with a Type 0 CLA (like on TMS320F28035) as a Type 1 CLA.

    Regarding the importance of non-deterministic delays I think you are taking the issue too lightly. I’m writing control loops in hand-optimized assembly, which run at ~1.5MHz. I only have a few dozen instructions for each loop and I need to know exactly what happens and when.

    Having random delays of even a few cycles can wreak havoc in the control scheme. Imagine for a second that it results in a write to a ePWM comparator happening one cycle *after* the transfer from shadow to active register instead of one cycle before? The consequence is a control loop that randomly incurs delays of one full control period.

    It might have made more sense to give absolute priority to the CLA.

    Kind Regards,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru** 116081 points

    Hi,

     My bad, I got mixed between peripheral names. My question was whether the arbitration scheme was the same with a Type 0 CLA (like on TMS320F28035) as a Type 1 CLA.

     

    Arbitration scheme is not related to CLA type but device. On F28035 device, RAMs were either mapped to CPU or CLA (not both) hence there was no arbitration. On this device arbitration is provided so that data can be shared run time. 

     Regarding the importance of non-deterministic delays I think you are taking the issue too lightly. I’m writing control loops in hand-optimized assembly, which run at ~1.5MHz. I only have a few dozen instructions for each loop and I need to know exactly what happens and when.

    Arbitration only applies to only data access and not for code execution. RAM from where CLA is executing the code is dedicated to CLA and CPU does not have access to it. If one CPU cycle delay due to arbitration is big concern then avoid simultaneous access to same RAM block from CLA and CPU.

    Regards,

    Vivek Singh 

  • 0 in reply to Vivek Singh
    Expert 2595 points

    Vivek,

    You write the following:

    "On F28035 device, RAMs were either mapped to CPU or CLA (not both) hence there was no arbitration. On this device arbitration is provided so that data can be shared run time."

    I disagree. On the F28035 device there was run-time data sharing with these message RAMs. Just look at Appendix A in the CLA datasheet SPRUGE6B: Message RAMs consist of two blocks. These blocks are for passing data between the main CPU and the CLA.

    • For the CLA to CPU message RAM the highest priority is CLA writes.
    • For the CPU to CLA message RAM the highest priority is CLA read.

    This scheme was perfect. Whatever happens the CLA cannot be delayed by the CPU. Round-robin arbitration was not necessary in order to share data.

    "If one CPU cycle delay due to arbitration is big concern then avoid simultaneous access to same RAM block from CLA and CPU."


    How? Do I have to wait for the MIRUN flags to be cleared every single time I need to write a control parameter or to read the result of a computation?

    Pierre

     

  • 0 in reply to Pierre Bouchet1
    TI__Guru** 116081 points
    Pierre,

    I was talking about the data RAM. Incase of MSG RAM you are right the scheme has been changed on this device. To avoid simultaneous access Instead of MSG RAM use data RAM and have two different buffers (Ping-Pong scheme) in different RAM blocks. Again it depends on the usecase and application so it may not be possible in all the case.

    Regards,

    Vivek Singh