• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1766 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.

TMS320F28069: CLA task duration calculation

Rein Kadastik
Prodigy 150 points
Part Number: TMS320F28069
Other Parts Discussed in Thread: CONTROLSUITE

How to exactly calculate the duration of the CLA task? What overheads I should consider?

For example if we take the DCL SDK v1_00_00_00 from the ControlSuite then in the file DCL_PI_CLA.asm there are 23 single-cycle commands. However in the DCL user guide section 4.4.1 table 4-1 it is said that the execution takes 33 cycles. Where does the overhead come from? Is it the pipeline? is it the calling convention?

So how to accurately calculate the performance of given method?

Also what extra overhead there is for CLA tasks? How many cycles it takes from for example the ADC interrupt to the first command execution of CLA task?

I try to calculate whether my CLA tasks fit within the available time window or not and would like to have methodology for doing that.

  • 0
    TI__Mastermind 27200 points
    The DCL function was benchmarked from a C task using a free running PWM timer, like this:
    ct1 = EPwm1Regs.TBCTR;
    uk_cla = DCL_runPIc(&pi_cla, rk_cla, yk_cla);
    ct2 = EPwm1Regs.TBCTR;
    delta_ct = ct2 - ct1;

    The result includes function calling over-head plus a couple of cycles to write the result and read the PWM timer. I anticipated a user would call the function this way and would want an indication of how long the whole operation takes. Optimization was turned off. If you were to measure cycles from the start to the end of the actual assembly module, then yes, the result would be about 23.

    It really depends how you are going to use the function. If you're writing the task in C then you will see the over-head above. It you're willing to hand code in assembly then you can reduce that somewhat.

    Regards,

    Richard
  • 0 in reply to Richard Poley
    TI__Mastermind 32995 points
    Hi,

    Richard has posted the best solution for profiling the actual code in a CLA task.

    However, there is also some overhead as you mentioned due to triggering the CLA task and notifying the C28x that it has completed.

    In order to test this overhead, you could use a timer on the C28x to time the start and stop of the CLA task.
    1) start the timer.
    2) start the CLA task via SW.
    3) Block on MIRUN bit being cleared.
    4) Stop the timer.

    Now, in step three, you will need some NOPs between step 2 and step 3, because it take a few cycles for the CLA to begin executing after being forced and for the MIRUN bit to be set. Additionally, if you are blocking in a loop on the C28x reading the MIRUN bit, depending on when the bit is cleared in the loop and when it is read, you will incur some additional overhead in the timing.

    As a worst case, I would estimate about 7 cycle overhead when starting from C28x and 7 cycle overhead when stopping. Those are not exact numbers, but what I would consider worst case.

    Regards,
    sal