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

TMS320F28379D: Benchmarking FPU DSP library RFFT_f32_mag function()

TIDR
Genius 9355 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMS320F28377D

We are trying to benchmark the a function F2837x_RFFT example from FPU DSP library on a F28379 launchpad. The following questions have come up:

  1. For the benchmark listed in the FPU DSP user guide, what is that benchmarked on? Is it on a Launchpad and if so which device and configuration?
  2. The examples as default for F2837x_RFFT as default uses TMS320F28377D in the CPU selection. Do you suggest changing this to F28379 for running on that Launchpad?
  3. When we do change the CPU to F28379D and rebuild we get errors and even on changing back the errors don’t go away. Why is this?
  4. On the launchpad on running the F2837x_RFFT example N=128 with different configurations and using a GPIO to measure the time interval different results are obtained for each configuration
  • FLASH_FASTRTS took 10.41us to run the instruction RFFT_f32_mag_TMU0(hnd_rfft)

  • FLASH_TMU0_TABLES took 10.41us on the same line

  • RAM took 5.48us on the same line

  •  RAM_FASTRTS took 5.48us on the same line

  • Do these processing times make sense? None of these correlate to actual benchmarks mentioned in the document which RFFT_F32_mag_TMU0 should take 289 cycles (1.445us) when N=128.

5. Is there any additional changes that need to be made to the example to run on a F28379D launchpad to get better performance of the example - linker code/data placement or options etc?

Thanks for the help!

  • 0
    TI__Mastermind 26845 points

    Dipa,

    When you change the device variant to 28379d, the linker command file automatically changes, and the RTS library as well (to <automatic>). If you expand the project to view the files in CCS, you will see that the existing .cmd files are not longer included (F2837xD_FPU_RFFT_lnk.cmd and F2837xD_Headers_nonBIOS_cpu1.cmd). You should right click them and uncheck the "Exclude from build" option. With this, the project builds, runs, and passes for me.

    The 28377d and 28379d appear to come in different packages; memories are the same, so I don't see a need to switch.

    On the performance side, agree the information could be better documented in terms of how the benchmarks were computed.

    I am using CCSv8.2, 28379d launchpad, connect to CCS and run the project, placing breakpoints at and after RFFT_F32_mag_TMU0 . Use CCS to enable Clock (in the CCS Debug perspective, select Run->Clock, and you will see a clock number on the bottom right corner of CCS, double click to zero out).

    I get the same numbers stated in the table for the RAM build configuration. The GPIO technique to measure cycles is not as accurate. I am not sure how much attention they paid to the various build configurations. I switched to RAM_TMU0 (which should really be the same as the RAM configuration since that also has tmu0 enabled)., and the project didn't Pass.

    Thanks,

    Sira

  • 0 in reply to Sira Rao80
    TI__Genius 9355 points

    Thanks! With this information the issue is now resolved.