C66x DSPLIB: DSPF_sp_fircirc

Hi,

Thanks for your post.

In my opinion, the _cn ending means natural C code which is the reference code not using intrinsics.

I believe, you would need to choose the C-File with the intrinsics to make a meaningful comparison.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

-------------------------------------------------------------------------------------------------------

Hello Sivaraj,

Thank you for your reply. Sorry it's hard to understand. I think that a result of DSPF_sp_fircirc_cn is correct, but a result of DSPF_sp_fircirc is not correct. I can't get correct result using DSPF_sp_fircirc.

Regards,
Kazu

I categorically disagree with TI analysis. Are you seriously suggesting that taking absolute value of result of comparison is intentional? Note that result of comparison if boolean, i.e. it's either 0 or 1, so that its absolute value is itself. This means that abs() can actually be omitted, so that what is executed is equivalent of if ((ptr_y_i[i] > FLT_THRES) || (abs(ptr_y_cn[i]) > FLT_THRES)). Note that given presented values, bunch of negatives and zeros, the first condition is always true. So that what is executed is equivalent of if ((abs(ptr_y_cn[i]) > FLT_THRES)).

As for not being able to confirm discrepancy reported in the originating post, which explicitly mentions uninitialized variable in DSPF_sp_fircirc. Kazu's analysis is totally correct. And the thing about uninitialized variables is that they can happen to have correct value in some situations. Probability varies with compiler version, optimization flags, call history... The fact that it happens to be correct in simplest test project doesn't mean that it will always work in real life.

Andy Polyakov said:

Note that given presented values, bunch of negatives and zeros, the first condition is always true. So that what is executed is equivalent of if ((abs(ptr_y_cn[i]) > FLT_THRES)).

I meant to write "the fist condition is always false". If it was always true, then second abs would never even execute and equivalent code would have been if (1). Once again, this is for presented data, not universal case.

Hello Andy,

Thank you for your post with same opinion. Actually I got chances to get correct and incorrect value when I ran the function. I want to investigate the cause of the difference.

Regards, Kazu

Hello Asheesh,

Thank you for your comment. Could you try the following program? I put a dummy code. I think A20 register is used by "i" in  DSPF_sp_fircirc library. You will see a different value between ptr_y_i and ptr_y_cn.

clock_t time_i(int nh, int ny)
{
    clock_t t_start, t_stop;
   
    /* ------------------------------------------------------------------- */
    /* Measure the cycle count                                             */
    /* ------------------------------------------------------------------- */
    t_start = _itoll(TSCH, TSCL);
    asm(" mvk 15, a20");
    DSPF_sp_fircirc(ptr_x, ptr_h, ptr_y_i, 0, NC, nh, ny);
    t_stop = _itoll(TSCH, TSCL);
 
    return t_stop - t_start;
}

Regards,
Kazu

Hello Asheesh,

Could you give me your reply?

Regards,
Kazu

It occurred to me that we have remained blind to another problem with mentioned conditional statement in DSPF_sp_fircirc_d.c. I mean originally mentioned

if (abs((ptr_y_i[i]) > FLT_THRES) || (abs(ptr_y_cn[i]) > FLT_THRES))

And the problem is that abs() calculates absolute value of an integer. This means that if you pass floating point value, compiler will convert it to integer, or simply put omit fraction part, prior passing value to abs(). So that 0.9 as well as -0.9 becomes 0, 1.9 becomes 1, -1.9 becomes -1, etc. And then integer number is compared to 1E-20. Well, it could have been compared to any number less than 1. The fact that it's compared to small floating point number can't mean anything else but that intention was to compare absolute value of a floating point number, not one converted to integer.

If we again have closer look at presented data, we'll see that ptr_y_i consists of a number of negative numbers and zeros. As already discussed, this means that first term of condition is always false. And if we look at ptr_y_cn, we'll see that it too consists of same amount of negative numbers and zeros. And the thing is that neither of absolute values of those non-zero numbers in ptr_y_cn are larger than or equal to 1. This means that even second term of condition is always false. And as both terms are always false, pct_diff is never assigned non-zero value, consequently max_pct_diff is never assigned non-zero value, consequently result for given inputs is always reported as successful. Once again, for presented data set.

It should be noted that half-fixed first condition, i.e. abs((ptr_y_i[i]) > FLT_THRES) -> (abs(ptr_y_i[i]) > FLT_THRES), exposes difference exclusively because absolute values of couple of ptr_y_i elements are larger than 1. If absolute values of all elements were less than one, even suggested modification wouldn't report difference.

Bottom line is that intended conditional statement has to be:

if ((fabsf(ptr_y_i[i]) > FLT_THRES) || (fabsf(ptr_y_cn[i]) > FLT_THRES))

But we shouldn't forget that even though this is glaring problem, the real problem remains uninitialized value in DSPF_sp_fircirc.c. Real in sense that it's the one that will affect real-life application. I mean DSPF_sp_fircirc_d.c is just a test program which is supposed to convince you that high-performance DSPF_sp_fircirc.c produces sensible result.

Hello Asheesh,

I upload my project. Could you check it? My compiler version is v7.4.12. I just link a pre-build library. I think that A20 register is used as "i" in DSPF_sp_fircirc. My application (DSPF_sp_fircirc_d.c) used A20 register explicitly for test. In effect, our application will use freely each register. I mean that A20 register data may be changed by our application. Once again, "i" should be initialized in DSPF_sp_fircirc.

Regards,
Kazu

c66x_dsplib.zip