NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
C674x DSPLIB Known Issues
Contents
Introduction[edit]
This page lists known issues with the C674x DSPLIB. This page is current for the v12 release.
DSPF_sp_fftSPxSP and DSPF_sp_ifftSPxSP Functions Overwrite the Input Buffer[edit]
Status[edit]
Active as of v12.
Description[edit]
The updated FFT and IFFT functions (DSPF_sp_fftSPxSP and DSPF_sp_ifftSPxSP) both use their input buffers as scratch memory during computation. This means that the original input buffer contents are lost.
Cause[edit]
N/A
Workaround[edit]
Copy contents of input buffer before calling these functions if the input data is needed for another purpose.
DSPF_sp_fircirc Demo Application Sets csize Incorrectly[edit]
Status[edit]
Active as of v12.
Description[edit]
The demo application for DSPF_sp_fircirc incorrectly uses csize as the number of elements in the circular input array. The correct usage is to use csize to indicate the size in bytes of the input array.
Cause[edit]
N/A
Workaround[edit]
Change all instances of 1 << (NC + 1) to 1 << (NC - 1).
Some Kernels Perform Poorly With CG Tools v6.1.11 or Later[edit]
Status[edit]
Active as of v12.
Description[edit]
The cycle count for the optimized C and natural C implementations for some kernels is markedly worse when using CG Tools 6.1.11 or later. The following kernels are affected:
- DSPF_sp_maxval
- DSPF_sp_minval
- DSPF_sp_maxidx
The cycle counts of the affected functions are as high as three times the normal values. The library (i.e. dsplib674x.lib) is pre-built with v6.1.9 of the code generation tools. This problem will only manifest if you rebuild the library yourself using a later version of the code generation tools.
Cause[edit]
This problem only occurs for codegen tools of version 6.1.11 or higher. (At the time of this writing, the highest available version was 6.1.13.) The newer tools balk at setting a float value using a hex integer representation without an intrinsic.
Workaround[edit]
Unless you want to rebuild the library, no action is required. When rebuilding the DSPLIB, use version 6.1.9 of the codegen tools. Alternatively, the code can be changed to work with newer versions of the codegen tools:
DSPF_sp_maxval, maxidx (old) | DSPF_sp_maxval, maxidx (new) |
---|---|
<syntaxhighlight lang="c">*((int *)&max1) = 0xff800000;
|
<syntaxhighlight lang="c">max1 = _itof(0xff800000);
max2 = _itof(0xff800000); max3 = _itof(0xff800000); max4 = _itof(0xff800000);</syntaxhighlight> |
DSPF_sp_minval (old) | DSPF_sp_minval (new) |
---|---|
<syntaxhighlight lang="c">*((int *)&min1) = 0x7f800000;
|
<syntaxhighlight lang="c">min1 = _itof(0x7f800000);
min2 = _itof(0x7f800000); min3 = _itof(0x7f800000); min4 = _itof(0x7f800000);</syntaxhighlight> |
DSPF_sp_fftSPxSP Only Supports n <= 8K[edit]
Status[edit]
Fixed in release v12. New maximum length is 64K.
Description[edit]
The DSPF_sp_fftSPxSP function supports a smaller maximum FFT size than the legacy FFT algorithms, DSPF_sp_cfftr2_dit and DSPF_sp_cfftr4_dif. The maximum size of 8K is too small for certain applications
Cause[edit]
The 8K limitation originated in the C67x DSPLIB. With the C674x DSP core, it is possible to enhance the mixed radix algorithm to support larger n. This work was not done in time for the first release of the C674x DSPLIB.
Workaround[edit]
Use the attached updated FFT/iFFT code that allow FFT/iFFT upto 64K taps. This updated code will be included in a future release of the DSPLIB. (Update: this code is now included in the standard DSPLIB installation as of v12.)
DSPF_sp_cfftr2_dit Fails for n = 32K[edit]
Status[edit]
Fixed in v12.
Description[edit]
Calling DSPF_sp_cfftr2 with n = 32K (32768 or 0x8000) causes the DSP to crash or hang. This problem does not occur for smaller n.
Cause[edit]
This function is implemented by unchanged legacy code from the C67x DSPLIB. The function itself has no problem and will work with n = 32K. However, there is a typo in the C header file distributed with the C674x DSPLIB (src/DSPF_sp_cfftr2_dit/DSPF_sp_cfftr2_dit.h) that casts n as a signed short. This causes the value 32K (or 0x8000) to be sign extended to 0xFFFF8000 when it is passed to the ASM library function.
Workaround[edit]
In the file src/DSPF_sp_cfftr2_dit/DSPF_sp_cfftr2_dit.h, change "short n" to "unsigned short n". You do not need to change or rebuild the library itself.