2021-03-09 14:52



  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • Brentbin Brentbin 1月前


    To start with, there is a demonstration app. (DSPF_sp_ifftSPxSP_d.c) for DSPF_sp_ifftSPxSP kernel in the DSP library package which is a complex inverse FFT with mixed radix driver code tests the kernel and reports the benchmark results of CPU cycles (Success/Failure). If you run this project first, you will be able to validate the usage of this kernel in your scenario which is in the installation path as below:
    Next, please refer the below wiki for the C674x DSPLIB Known issues for DSPF_sp_ifftSPxSP kernel:
    Also, please refer the below E2E thread for the similar usecase as yours which would give you an idea on the impact of DSPLINK intervention with the dsplib but it is for OMAP3530 EVM and
    As per your usecase, there could be many possibilities but please make sure that the DSP and ARM are exchanging same input and output data through DSPLINK. You can exchange checksum data on both ARM & DSP to ensure the same.
    1. Probem could be with the usage of dsplib function for IFFT
    2. It could be the data mismatch between ARM and DSP through IPC
    3. Issue could be with the array/buffer size between ARM and DSP through DSPLINK
    4. might be a scaling range issue
    Please also refer the below wiki to get an idea on how to debug the dsp side of a dsplink application,
    I also recommend you to refer the DSPLINK API documentation which would be in the dsplink source installation path as below:
    点赞 评论 复制链接分享