• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 226 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.

How to get the basic floating-point operations count on a C64x fixed-point DSP?

Huan Hou
Expert 1505 points

Hi, all

We have an algorithm to port to C64x DSPs and now the algorithm is implemented in floating-point. So firstly we have to give a rough estimation of the complexity, an easy way could be to count the total floating-point operations and then estimate the cycles required for the same number of fixed-point operation. And in order to count the number of floating-point operation, I rebuild the rts library with debug info following the guide here.

http://processors.wiki.ti.com/index.php/How_to_rebuild_the_C6000_RTS

But even with the debug rts library, I can't get the number of floating-point operations after I profiling the algorithm using CCSv3.3. I just add the -g macro to enable debug information in RTS library, is there anything else I miss for the rebuild of the RTS library?

Or any other hint to estimate the performance required based on present floating-point algorithm?

 

Thanks

Touse

  • 0
    TI__Guru*** 125430 points

    I don't think you need to rebuild anything.  I believe CCS Function Profiling would be a better method of counting how many multiplies you're doing:

    http://processors.wiki.ti.com/index.php/Quick_Tips#Profiling.C2.A0

    I remember using this functionality years ago, so here would be my tips...  Each function that gets profiled will get a breakpoint set inside it.  So if you have a big program with lots of functions you probably don't want to profile everything or it will be very slow.  Doing the profiling on hardware can actually be slower than using a simulator.  That's because the program is (silently) halting at all the breakpoints.  Stopping and starting the target is much slower for hardware than it is for a simulated environment, so this is the one case where a simulator can actually be faster!

    If you have any questions on the profiling itself I recommend posting a separate question in the CCS forum as that will be a more appropriate spot for that type of issue.

    Brad