• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 1206 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.

DSP cycle counter

Weihua Sheng
Intellectual 600 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I am facing an issue to measure the time on DSP for some applications running on OMAP3530 (Mistral EVM). Details follow:

- We use the 64-bit cycle counter (TSCL/TSCH) to do some time measurement on DSP for a portion of the code, basically 

get_tsc();

// some code here

get_tsc();

- After looking into the results, we found out that the time measured (delta from the code snippet above) seems less than the real elasped time. That is, (delta) cycles/freq < real elapsed time.

 

Is it possible that during the execution of the some code in between, the DSP stalls or sleeps and thus the TSC couter does not increase? The code does some exchaning data between DSP and ARM (using MPCS-based shared buffer) - it is likely that the data is not available (so we do TSK_yield). Any comments from TI or other users? The DSP cycle counter runs freely all the time or are there possibilities that it can stop?

 

Thanks a lot!

 

 

  • 0
    TI__Guru* 84110 points

    The TimeStamp Counter will start to run once it is started by a write. It will continue to run until it the DSP's RESET is asserted or the DSP's clock is stopped.

    TSK_sleep and DSP stalls will not affect TSC.

    I might not have the latest support files, but I did not find a function reference for get_tsc(). Is this a system function or one that you wrote?

    In C code, I like to use

    llStartTime = _itoll( TSCH, TSCL );

    to copy the counter registers into a long long. You have to #include <c6x.h>, of course. You would want to make sure the optimizer does read the registers in the right order. I have checked, and every time it has read TSCL first. I am not sure why, but it works.

    The operation of the TSC should not be a variable in your timing mismatch. it should be a useful tool to help figure out why you have the mismatch.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • 0 in reply to RandyP
    Intellectual 600 points

    Hi Randy,

     

    Thanks for the quick reply. I am looking into why I have a mismatch. Probably a related question: I am using the BIOS function, GBL_getFrequency(), to get the DSP clock frequency, and the following DSPCPUcycles = (cycle_count1 - cycle_count2) * CLK_cpuCyclesPerHtime() / GBL_getFrequency() to get elapsed time. Does GBL_getFrequency() always return the corrent running clock frequency of DSP? Or I should look into somewhere else to get clock freq of DSP?

     

    Thanks a lot!

     

  • 0 in reply to Weihua Sheng
    TI__Guru* 84110 points

    Your description agrees with the BIOS User's Guide. The BIOS Forum will have more people who are more knowledgeable about specific BIOS functions.

    If you would like to determine the DSP clock frequency outside of the DSP program, please see this forum post. The comments in the code explain how to use this simple routine to measure true clock frequency. It will not work like GBL_getFrequency within your program, but it will confirm for you that your clock frequency is set correctly.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 600 points

    Thank  you. I will ask BIOS forum further.