The dsp_bfp.h uses "unsafe" and causes the below error when included by a C file.
This causes issues with libraries like lib_radar and any other C file that includes "dsp.h".
That should be fixed because it currently prevents lib_dsp functions to be used in C code which is a key requirement.

/Users/thomas/dev/IFX/IFX_radar_smartmic/xmos_soliC/lib_dsp/lib_dsp/api/dsp_bfp.h:60:43: error: expected ')'
void dsp_bfp_shl2( dsp_complex_t * unsafe pts, const uint32_t N,
^
/Users/thomas/dev/IFX/IFX_radar_smartmic/xmos_soliC/lib_dsp/lib_dsp/api/dsp_bfp.h:60:18: note: to match this '('
void dsp_bfp_shl2( dsp_complex_t * unsafe pts, const uint32_t N,
^
In file included from ../src/get_chirps.c:9:

Issues:

• Test not compiling for xcore-ai - requires a change to the wscript and pytest runner

I'm trying to build app_vector with tools 14.4 and get an error.
xmake
Checking build modules
Using build modules: lib_dsp(4.1.0)
Rebuild .build/_iflag.rsp
Analyzing dsp_adaptive.c
/Users/thomas/dev/git/external/ThomasGmeinder_github/lib_dsp/lib_dsp/src/dsp_adaptive.c:21:29: error: function definition is not
allowed here
const int32_t q_format) {
^
/Users/thomas/dev/git/external/ThomasGmeinder_github/lib_dsp/lib_dsp/src/dsp_adaptive.c:56:3: error: function definition is not allowed
here
) {
^
/Users/thomas/dev/git/external/ThomasGmeinder_github/lib_dsp/lib_dsp/src/dsp_adaptive.c:91:2: error: expected '}'
}
^
/Users/thomas/dev/git/external/ThomasGmeinder_github/lib_dsp/lib_dsp/api/dsp_vector.h:186:3: note: to match this '{'
) {
^
3 errors generated.
xmake[1]: *** [.build/_l_dsp/src/dsp_adaptive.c.pca.xml.decouple] Error 1
xmake: *** [analyze] Error 2

Will update with more failure cases. Tests can be run using pull request #122

Integer overflow started to occur in lib_dsp_fft_inverse_complex.
Looks like this is caused by this commit.
b049048
It adds accuracy (adds LSB using extract) but looks like this now causes overflows.

Issue raised as part of PR #149

app_design is failing:
http://swdb.xmos.local:8000/products/testinstance/206465/

Because bug was fixed in #28
but design_test.expect was't updated.

Fixed in PR #116
Is this desired?

Lib_dsp has 6 test failures. This is 100% of the dailyLibs regression failures. Please resolve ASAP.

lib_dsp
->standard_lib_tests
->changelog_check
->FAIL

lib_dsp
->standard_lib_tests
->source_check
->FAIL

lib_dsp
->simple_tests
->app_design
->FAIL

lib_dsp
->simple_tests
->app_fft_short_int
->[config=complex]
->FAIL

lib_dsp
->simple_tests
->app_transforms
->[config=complex]
->FAIL

lib_dsp
->simple_tests
->app_transforms
->[config=tworeals]
->FAIL

The library could do with a way of enforcing double word aligned inputs where double-word instructions such as LDD are used in implementation (eg dsp_filters_biquads)

The problem is that you might write your code one way, say with data on stack, and only then find run into alignment issues, and have to change to another way such as global variables

Could it use a 64bit data type? Or maybe there is a attribute/pragma for it?

Reported on xcore.com

The lib_dsp/.cproject file appears to have been committed with some of the inline diff markers still in there. e.g.

                                    <listOptionValue builtIn="false" value="__XCC_HAVE_FLOAT__=1"/>
                                    <listOptionValue builtIn="false" value="_XSCOPE_PROBES_INCLUDE_FILE=&quot;/tmp/ccjsPcFI.h&quot;"/>
                                </option>
<<<<<<< HEAD
                                <option id="com.xmos.xc.compiler.option.include.paths.1034653062" name="com.xmos.xc.compiler.option.include.paths" superClass="com.xmos.xc.compiler.option.include.paths" valueType="includePath">
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}\target/include/xc&quot;"/>
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}\target/include&quot;"/>
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}\target/include/clang&quot;"/>
=======
                                <option id="com.xmos.xc.compiler.option.include.paths.497342305" name="com.xmos.xc.compiler.option.include.paths" superClass="com.xmos.xc.compiler.option.include.paths" valueType="includePath">
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}/target/include/xc&quot;"/>
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}/target/include&quot;"/>
                                    <listOptionValue builtIn="false" value="&quot;${XMOS_TOOL_PATH}/target/include/clang&quot;"/>
>>>>>>> 4cdfda4574e272900c222fcb31e7eeb5a4ee6712
                                    <listOptionValue builtIn="false" value="&quot;${workspace_loc:/app_filters}&quot;"/>
                                    <listOptionValue builtIn="false" value="&quot;${workspace_loc:/app_filters/src}&quot;"/>
                                </option>

Here is a suggested API for fft work:

typedef struct {
    int32_t re;
    int32_t im;
} lib_dsp_fft_complex_t;

typedef struct {
    int16_t re;
    int16_t im;
} lib_dsp_fft_complex_short_t;

void lib_dsp_fft_bit_reverse( lib_dsp_fft_complex_t pts[], unsigned N );
void lib_dsp_fft_inverse(lib_dsp_fft_complex_t pts[], unsigned N, const int32_t sine[]);
void lib_dsp_fft_forward(lib_dsp_fft_complex_t pts[], unsigned N, const int32_t sine[]);
void lib_dsp_fft_unmangle_real_inputs(lib_dsp_fft_complex_t pts[], unsigned N);
void lib_dsp_fft_mangle_real_inputs(lib_dsp_fft_complex_t pts[], unsigned N);

void lib_dsp_fft_bit_reverse_short( lib_dsp_fft_complex_short_t pts[], unsigned N );
void lib_dsp_fft_inverse_short(lib_dsp_fft_complex_short_t pts[], unsigned N, const int16_t sine[]);
void lib_dsp_fft_forward_short(lib_dsp_fft_complex_short_t pts[], unsigned N, const int16_t sine[]);
void lib_dsp_fft_unmangle_real_inputs_short(lib_dsp_fft_complex_short_t pts[], unsigned N);
void lib_dsp_fft_mangle_real_inputs_short(lib_dsp_fft_complex_short_t pts[], unsigned N);

The mangle and unmangle functions could do with a better name and I'm open to suggestions. The purpose of unmangle is to take the complex output of two N length real ffts and reorder them such that the array represents two N/2 length FFTs. mangle will do the opposite, i.e. take two N/2 length complex FFT and combine them such that they can be inverted with and iFFT.

This will mean a reduced amount of code, testing, docs and that FFTs can be fit into half the memory footprint.

Wrong vector mean formula: /* Vector mean: R = (X[0] + X[N-1]) / N
Should be: /* Vector mean: R = (X[0] + X[1] + ... + X[N-1]) / N

The formulas for the other functions in dsp_statistics.h have a similar problem.

Tests affected:

• tests/test_fft_forward
• tests/test_fft_index_bit_reverse
• tests/test_fft_inverse
• tests/test_fft_performance
• tests/test_fft_short_long
• tests/test_fft_split_and_merge

Issues:

• Tests not compiling for xcore-ai, requires a header file "generated.h" generated by xmostest

structure name has "ds3" in it rather than "os3" in the os3 implementation

https://github.com/xmos/lib_dsp/blob/master/lib_dsp/src/os3/dsp_os3.c#L50

does not support a length of 0. Either needs documenting or fixing

Two of the three app_fft_short_int test cases are failing as follows:

• app_fft_short_int_two_complex

lib_dsp::simple_tests::app_fft_short_int FAIL
ERROR: line 3 of output does not match expected
ERROR: expected: 1.00000, 0.00000
ERROR: actual: 0.99997, 0.00000
ERROR: length of expected output greater than output

• app_ft_short_int_complex

lib_dsp::simple_tests::app_fft_short_int FAIL
ERROR: line 3 of output does not match expected
ERROR: expected: 1.00000, 0.00000
ERROR: actual: 0.99997, 0.00000
ERROR: length of expected output greater than output

This seems like it could be the same as issue #18 (and therefore also possibly related to #14).

/buildslave/swnb/apps/DailyVDA_centos_5_64bit/build/sb/lib_dsp/lib_dsp/src/lib_dsp_math.c:264:9:
warning: unknown pragma ignored [-Wunknown-pragmas]

pragma unsafe arrays

(should be #pragma unsafe-arrays)

I've not fixed since this would change the behaviour.

Issues:

• Test not compiling for xcore-ai - wscript and pytest runner need updating

Documentation exists in api/dsp_bfp.h but is not included in the rst.

The new Q format macros cannot be used to initialise global data, as they are non constant.
It looks like this issue was introduced in commit bc1961e, which changed the macros to use the round function.

For reference the Q format macros are used to initial globals in the following files (and therefore apps of the same name):

• app_adaptive.xc
  • fir_coeffs
• app_filters.xc
  • Src
  • firCoeffs
  • firCoeffsInt
  • iirCoeffs
• app_matrix.xc
  • Src1
  • Src2
• app_statistics.xc
  • Src
  • Src2
• app_vector.xc
  • Src
  • Src2
  • Src3

Resulting in build errors such as the following:

Analyzing app_adaptive.xc
../src/app_adaptive.xc:24:3: error: initializer element is not constant
  Q31(+0.0391607),Q31(+0.0783215),Q31(+0.0191607),Q31(+0.01531791),Q31(-0.03098222),
  ^~~~~~~~~~~~~~~
/Users/samc/sandboxes/swapps_box/lib_dsp/lib_dsp/api/lib_dsp_qformat.h:20:16: note: expanded from macro 'Q31'
#define Q31(f) round(f * (double)(unsigned)(1<<31)) // needs unsigned cast because bit 31 is 1
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Looks like incorrect reporting of window selection switch and typo at line 27

Also, should line 96 be 0x7fffffff (max_int)?

__attribute__((deprecated("Please use 'src_ds3_init' in lib_src instead")));

You get this even if you don't use it, plus loads more. It's a good warning but shouldn't be visible if you are not using the function.

viz:

Using build modules: lib_dsp(3.0.0)
Analyzing dsp_adaptive.c
Analyzing dsp_design.c
Analyzing dsp_filters.c
Analyzing dsp_math.c
Analyzing dsp_matrix.c
Analyzing dsp_statistics.c
Analyzing dsp_tables.c
Analyzing dsp_vector.c
Analyzing app_fft.xc
../src/app_fft.xc:7:10: fatal error: 'lib_dsp.h' file not found

include <lib_dsp.h>

This then goes on to produce a whole sequence of compile errors.

There are several functions e.g. dsp_bfp_clz_uint8 that only take a single argument. The _bfp label in a function name should only be used for functions that are BFP specific and can't be used for non-bfp data.
This would simplify other function names too: _vect could be removed from all _bfp functions since _bfp implies _vect

This AppNote as it currently stands fails to compile in 14.2 with the following:

Compiling lib_dsp_adaptive.c
Compiling lib_dsp_design.c
Compiling lib_dsp_filters.c
Compiling lib_dsp_math.c
Compiling lib_dsp_matrix.c
Compiling lib_dsp_statistics.c
Compiling lib_dsp_tables.c
Compiling lib_dsp_vector.c
Compiling app_fft_double_buf.xc
xcc1: terminated due to internal unrecoverable error
For bug reporting instructions, please see:
http://www.xmos.com/support

Robert has done some investigating a below are his comments...

The problem is with app_fft_double_buf.xc viz:
"/buildslave/swnb/tools/centos_6_64bit_nightly_rel_14_2/build/sb/Installs/Linux/External/Product/libexec/xcc1llvm" "-O2" "-analysis" .build_tworeals/pca.xml -march=xs2a .build_tworeals/app_fft_double_buf.xi

Interestingly, it does not always crash.

I believe the problem is a local static declaration in a function that get replicated (don't ask).
There is some shallow copying of objects going on, thus we try to delete the same object twice.
Bit of a dice roll regarding what is present in the memory on the second call.

ifdef FIX

    static SIGNAL_ARRAY_TYPE output[N_FFT_POINTS];

endif

do_fft() {
...
while (1) {
// swap buffers
select {
...

ifndef FIX

    static SIGNAL_ARRAY_TYPE output[N_FFT_POINTS];

endif

...

This is an issue that is fixed on 14.3 and master branches, however it cannot be back ported to 14.2 for the 14.2.1 release. Thus this AppNote needs updating such that the static is global as opposed to local to the function. This should then resolve the issues compiling on 14.2.

Colin.

Causing licence check fails:

Cannot find LICENSE.txt in /buildslave/swnb/apps/DailyLibs_centos_5_64bit/build/sb/lib_dsp/tests/tmp4i1CY6

The Jenkins nightly run of lib_dsp's develop branch on 16 June 2020 produced a test failure in lib_dsp::simple_tests::app_math. The simulator times out when testing dsp_math_cosh (see lines 516-521 of the console output). A subsequent run of the same commit of lib_dsp passed all tests, so likely an intermittent issue.

Issues:

This application note fails to build, producing the following error message:

Error: XN11052 Invalid or missing PageSize for device "bootFlash". Information: Device elements with attribute Class="SQIFlash" now also require PageSize, SectorSize & NumPages attributes to be set. Values for these are likely to be found in the datasheet for the chosen flash.

E.g. dsp_<bfp,float,complex,etc.>_<add,sub,etc.>_<int32,uint32,int8,etc.>()

Thirty one source files in lib_dsp currently conditionally compile portions of code based on the symbol __XS2A__. Typically the #else clause assumes an XS1 architecture. To ensure that the correct code is used when running on an XS3 architecture, the conditional compilation lines need updated to include the __XS3A__ symbol in their expression.

In the list below, the number in parenthesis states the number of instances of the __XS2A__ symbol in the file where the containing expression has not been previously updated to include the __XS3A__ symbol. The thirty one files are:

• dsp_bfp.h (1)
• dsp_math.h (1)
• dsp_filters.c (1)
• poly_eval.c (1)
• dsp_complex.xc (4)
• dsp_fast_float.xc (1)
• dsp_fft.xc (7)
• dsp_fft_real.xc (2)
• dsp_bfp_bit_reverse_shl.S (1)
• dsp_bfp_cls.S (1)
• dsp_bfp_shl.S (1)
• dsp_biquad.S (1)
• dsp_complex_add_vector.S (1)
• dsp_complex_fir.S (1)
• dsp_complex_hann.S (1)
• dsp_complex_mul_vector.S (1)
• dsp_fast_atan.S (1)
• dsp_logistics.S (1)
• dsp_min_vector.S (1)
• dsp_poly_eval.S (1)
• dsp_sqrt_xs2.S (1)
• dsp_fft_bit_reverse.S (1)
• dsp_fft_forward.S (1)
• dsp_fft_gc.S (1)
• dsp_fft_inverse.S (1)
• dsp_fft_inverse_DIF.S (1)
• dsp_fft_merge_spectra.S (1)
• dsp_fft_real_fix.S (1)
• dsp_fft_split_spectrum.S (1)
• dsp_fft_zero_reverse_forward.S (1)
• dsp_fft_long_short_conversion.S (1)

app_transforms is failing due to unexpected differences in the test output such as:

Line 3 of output does not match expected
  Expected: 1.0000000005, 0.0000000000
  Actual  : 0.9999999995, 0.0000000000
Line 4 of output does not match expected
  Expected: 0.7071067694, 0.0000000000
  Actual  : 0.7071067807, 0.0000000000

Based on when the test started failing to looks like it's related to a change introduced in #14, but I haven't tried going back through the commits to see where the rounding difference has come from.

Out of interest, how are the expected values for these tests generated?

e.g.

    int32_t vec1[1] = {1932};
    int32_t vec_result[1];
    dsp_vector_abs(vec1, vec_result, 1);
    // vec_result = {-1932};

There is a double precision fft with the same interface in audio_test_tools. We should regress against this so that we can test all FFT sizes and not need large generated tables to test against.

Some of the tests are run in multiple configurations, but do not specify a configuration value when creating the xmostest.ComparisonTestser object. This is causing the result of each subsequent test config that runs to overwrite the last in the results DB.

for example the function foo(a, b, c) where a=b+c
needs testing with foo(a, b, c) and foo(a,a, b) and foo(b, a, b).

Some of these functions will need the alias keyword adding to their prototype

The number of cycles taken by the sine and cosine functions has increased, causing test_math.py to fail:

Line 54 of output does not match expected
  Expected: Cycles taken for math.h sine function: 14112
  Actual  : Cycles taken for math.h sine function: 14113
Line 102 of output does not match expected
  Expected: Cycles taken for math.h cosine function: 14112
  Actual  : Cycles taken for math.h cosine function: 14113

Observations :
app note project doesn't import into xTIMEcomposer due to Resource name conflicts
app_complex and app_complex_fir not imported at all

If I get a break from support, I'll try to resolve.
J

Certain combinations of inputs cause an overflow in dsp_math-divide which causes it to yield incorrect output. For example, dsp_math_divide(0x02000000, 0x02000001, 24) gives a result of 0.

More generally, this will happen whenever dividend<divisor and (dividend<<32) / divisor is greater than a certain value (which depends only on q_format). When this happens, at the line

r = d << q_format | (d2 + (1<<(31-q_format))) >> (32-q_format);

d2 is already very near 0xFFFFFFFF, and the addition of 1<<(31-q_format) causes an overflow.

This could be avoided by not adding 1<<(31-q_format) (not rounding), or by explicitly checking whether an overflow is about to occur (i.e. d2 is greater than some number, which depends on q_format).

These cases are likely to arise when, for example, computing arctan() of an angle that happens to be near pi/4 (modulo pi/2)

Only values between 0.0312499 and 2 are correct for lib_dsp_math_sqrroot which is based on lib_dsp_math_invsqrroot

Other inputs cause large errors:
Maximum Positive Error: 2100030514
Maximum Negative Error: -2078536573
Number of values checked: 64
Percentage of 0 Error: 9.38%

Fixed on Fork by deploying an alternative algorithm (ported from sc_lib_fixed_point)
ThomasGmeinder@f222c48#diff-94a9ba5987c03e85832f5af40cdc748bR185

The test app_math.xc shows that the max absolute error is 280.
That's 280/(1<<24) == 1.67E-5 for Q8.24.
Is this acceptable?

Docs need updating for new functionality.

Minor suggestion : I'd put app_atan2_hypot code in app_math for consistency.

Issues:

• Test not compiling for xcore-ai, requires a header file "generated.h" generated by xmostest

In the app_adaptive.xc, change the first input parameter in dsp_adaptive_nlms from Q31(0.08) to Q31(0.0008), then will encounter the problem:
Normalized LMS 5
Unhandled exception: ARITHMETIC, data: 0x00000000

The problem should be the input value is too small to cause the dsp_math_divide to have a 0 divider.

This will happen when customer using the real world PCM samples (mute audio or very low amplitude audio samples)

Please advise if it is usage problem or lib code problem, thanks in advance.

Currently lots of separate asm() blocks which should be combined to single asm() block e.g.

    asm("ldd %0,%1,%2[8]":"=r"(b1),"=r"(b0):"r"(filter_coeffs));
    asm("ldd %0,%1,%2[8]":"=r"(s2),"=r"(s1):"r"(state_data));
    asm("std %0,%1,%2[8]"::"r"(s1), "r"(s0),"r"(state_data));
    asm("maccs %0,%1,%2,%3":"=r"(ah),"=r"(al):"r"(b0),"r"(s0),"0"(ah),"1"(al));
    asm("maccs %0,%1,%2,%3":"=r"(ah),"=r"(al):"r"(b1),"r"(s1),"0"(ah),"1"(al));

This is both neater and further removes the change of compiler interference.

Link to old PR here: #118

Test execution time could be reduced if we switched from using xsim to using axe.