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

C6727 DSP code benchmarking problem

anushree mahapatra
Intellectual 360 points

Hi,

I am trying to benchmark a windowing code on C6727 on CCS ver 3.3. Since I am not using DSP/BIOS, so am unable to use the CLK_getltime and the other functions, thus i used the basic clock() function before the start of the code and at the end of the code and tried to print the START,STOP variables. All I get is 0 values all the time.

Another method I tried is to enable the Profiler> enable CLOCK, and used the clock window. I put 2 breakpoints, one in the start of the code and one at the end of  the code, and i ran the code. After coming to the first breakpoint, i reset the clock window and then run the code to the next breakpoint. But the no. of cycles I see on the clock is quite huge for a very small DSPLIB function for just 10 elements. Using the benchmark formula for dsplib functions, i get very small no. of cycles but using it in a code, I get large no. of cycles.

Please help. Its urgently required for some alternative on benchmarking.

  • 0
    TI__Guru** 116980 points

    Anushree,

    One way to profile data at run-time would be to configure one of the on chip timer. You might find some basic timer code in the CSL package of the device.

    Newer DSP families have the time stamp register that gives absolute high resolution profile information, however this feature was not available on the C672x DSP family.

    You might want to post the clock issue on the CCS forums to understand, why this didn`t work for you. Did you benchmark the dsplib code on the hardware or on the simulator.  I know there have been some issues reported regarding clock APIs producing incorrect results on actual hardware. If you benchmark the code on the simulator, you might want to turn on the cache or place data in internal memory while trying it on the device.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 360 points

    I am not using the simulator. I am using XDS510 PP emulator. I am only passing 10 samples to the DSPlib function and benchmarked the code using the profile clock. But I am getting quite huge values and not similar to the cycles from the benchmark equations for DSPLIB function. Please help me.

  • 0 in reply to anushree mahapatra
    Expert 2210 points

    First, check that you are using the correct types, e.g. clock_t and cast that to a known type like long long and use the correct specifier %lld when printf()ing the value.

    If that is okay, then note that clock() gets the time from HOSTclock(), which communicates (relatively slowly) with the host via the JTAG connection, so it would not be surprising if a lot of DSP cycles passed before the value comes back to the DSP.  (I think HOSTclock() may work okay using the simulator instead of an actual DSP.)

    The best way to time execution on the DSP itself is to use one of the built-in TIMER devices instead of clock().  They're not hard to program.

     

  • 0 in reply to Douglas Gwyn
    Intellectual 360 points

    To configure the on-chip timer, you are referring to the TIMER_open function and TIMER_config right? those are not being recognised for C6727 dsp..I checked in the header file and the timer functions are not defined for C6727 chip. Thus what should I do to get the chip timer working for this dsp?

  • 0 in reply to anushree mahapatra
    Expert 2210 points

    The C6727 includes a different kind of timer, namely the real-time interrupt counter with digital watchdog.  (Refer to SPRS268E.)  DSP/BIOS uses counter 0 (probably for preemptive scheduling), so you have to use counter 1 and be careful not to disturb the settings used by DSP/BIOS.  Leave the digital watchdog disabled; also, you don't need to generate an interrupt since the free-running counter RTIFRC1 can be read at any time.  The counter counts SYSCLK2 cycles (probably150M counts/sec but you need to check how the PLL is configured to be sure) divided by the prescaler value in RTIUC1.  You set the prescaler to a value such that the counter doesn't wrap around while you're timing the execution.  Then obviously you read the counter at the start and at the end of the execution being timed, take the difference, multiply by the prescaler value, and divide by the SYSCLK2 frequency.  Good luck!