[C6713] Problem with DSPF_sp_biquad

attached kernels may be useful.. these are variety of IIR kernels written for 672x..

Brad and Gagan, your posts are very helpful!

Is there something that speaks against using the filter functions on a c6713? Do they have to be optimized differently for the c6713?

Thanks for your help!!!

Robert

Generally speaking you can compile C code for both 6713 and 6727.  You just need to make sure you compile the 6713 code for a 67x core (-mv6700) rather than for 67x+ core (-mv67p).

I haven't looked through all the code Gagan posted.  As long as there is nothing specific to the 672x such as an intrinsic that's not available on 671x then it should compile fine.

Brad

code should work fine for 671x too. just a recompile is enough.. few exceptions:

- Mixed precision kernels use newer instructions not present on 671x

- Some multichannel kernels may not compile at the same performance as 672x as 671x has 1/2 the number of CPU registers...

Please review the C code before using it..

Gagan

Brad,

Above mentioned are the only API's having problem or any other dsplib API's other than this can lead to the same problem? I am really worried to use the lib API's from TI.

Since, i have faced the same problem and just to avoid usage of dsplib other than above listed lead to catastrophic results!

Please let me know if any known bug in below mentioned API's which I have used in my application code:

  1. DSPF_sp_blk_move

  2. DSPF_sp_vecsum_sq

Thanks,

Balachandra

One of my customers did a lot of testing of DSPF_sp_blk_move in the presence of interrupts and he never had any issues with it.  I believe it's in good shape.

I couldn't find information good or bad on DSPF_sp_vecsum_sq.  If you don't "trust" the function you could simply disable/restore interrupts around the function call.  Pretty much all the issues are related to the way interrupts are being disabled in the functions.

FYI, for our newer devices (674x core) we have released an updated DSPLIB:

http://wiki.davincidsp.com/index.php?title=C674x_DSPLIB

There is talk about doing some additional work on that code so that we can compile a 67x, 67x+, and 674x version.  For now only the 674x version exists.  I'm not sure what device you're using, but if it's one of the newer 674x devices then you should definitely use this library.

Brad

Thanks for the info Brad.

I am using C6727 with ROM BIOS and application running with 10mSec HWI scheduler.

Thanks,

Balachandra

In addition to this,

Brad, can you please help me in resolving one more issue associated with C6727 UHPI bootloader.

Please see the below link for the query which I have already posted. Till now I have not received any response.

https://community.ti.com/forums/p/7529/29128.aspx#29128

Problem Description: 6727 UHPI communication with  PowerPC based host microprocessor(MPC-8248). 

The configuration of UHPI is single HPIA, multiplexed full word mode with Byte addressing option enabled. Sometimes while host tries to program the DSP (DSP is in UHPI boot mode), HRDY signal from DSP is continuously held HIGH for the entire duration of chip select and hence read/write access is failing. 

thanks,

Balachandra

Ok, I replied to your initial question.  Normally these kinds of strange behaviors are caused by something wrong with the hookup, i.e. improper timing or voltage levels.  Let's take the discussion to the other thread.

Brad,

We want to use DSPF_sp_biquad. Can we use same method that you mentioned for this API also? Will it work without any problem?

We also wanted to know if this has been fixed . If it is fixed where we can get the fixed versions of libraries in TI site?

Awaiting for reply

Thanks

Sudhee

Sudhee M S said:

We want to use DSPF_sp_biquad. Can we use same method that you mentioned for this API also? Will it work without any problem?

I don't know of any issues with DSPF_sp_biquad, i.e. you shouldn't have to do anything special besides following the required alignments, etc.

Sudhee M S said:

We also wanted to know if this has been fixed . If it is fixed where we can get the fixed versions of libraries in TI site?

It has not been fixed for 67x/67x+ and at this point I doubt it ever will, i.e. resources are focused on 674x and 66x.

Hi Brad,

Thanks for quick response.

Further browising about this problem i could find one thread where u have answered the questions. Here is the link. http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/t/30770.aspx

Why this restriction of Nx =6*x ? we are using TI DSP for time critical application . We can use DSPF_dp_biquad(), but conversion float to double and double to float taking much time(23cycle) it is huge. This problem is reported verylong back ,  why this has not fixed yet.!?

Thanks

Sudhee

Sudhee,

This issue may have been fixed in the C674x DSPLIB. Can you download the C674x DSPLIB from

http://focus.ti.com/docs/toolsw/folders/print/sprc265.html

and use the DSPF_sp_biquad API and use this in your C67x project

The documentation for this API is mentioned here.

http://processors.wiki.ti.com/index.php/C674x_DSPLIB#DSPF_sp_biquad_.28Biquad_Filter.29

If you are still having issues, please write to us at the mailing list mentioned here.

http://processors.wiki.ti.com/index.php/Software_libraries#Bug_Reports_and_feature_requests

Regards,

Rahul

Sudhee,

Just to clarify, the original DSPF_sp_biquad function for the 67x dsplib is not broken.  The documentation incorrectly states that nx must be a multiple of 3 when it should in fact be a multiple of 6.  In other words, it's a documentation error not a software error.  That restriction comes directly from the method in which the function was implemented.  The newer 674x DSPLIB implements the biquad differently and so that restriction no longer exists.

You did not mention what processor you are using.  If you are using a processor which utilizes the 674x core then you can use the 674x dsplib directly.  Otherwise you may need to extract the associated file and recompile for your core (e.g. 67x or 67x+).

Best regards,
Brad

Hi

Thank you very much Brad and Rahul.

I apologise for not mentioning the MY DSP. My DSP processor is TMS320C6727.

Now the problem is how to extract associted file from 674x library.. I will try doing that, if not successfull could you please help us..?

Thanks

Sudhee

Rahul,

As you suggested, I downloaded the C674x libraries and installed. I could find the source file for DSPF_sp_biquad() function , I added the .c file and .h file to c67x project and compiled. It compiled successfully and even when I run it was successful. I mean it is not crashing as earlier. But now the problem is it is taking large number of cycles. Here is the data. 

For 128 samples- Number of cycles it took was 21742. 

 It is very much greater than using ' DSPF_dp_biquad() with conversions'. I would expect here less than 3000cycles. Because DSPF_sp_biquad() function which crashes, when I tried with multiple of 6, ie 126 samples, number of cylcle it took was around 1930.

 I strongly believe I did something wrong.  Please suggest me how I can use DSPF_sp_biquad() with less number of cycles and without crash.

Thanks

Sudhee

Now that you've added C code to your project your performance will be dictated by how well the compiler optimizes it.  Please do the following to set file-specific compile options:

• Right click on the biquad C file and select Properties.
• Go to "Basic Options" for the C6000 Compiler
• Turn off symbolic debug and set the optimization level to 3.

Brad

Sudhee,

Since we were able to resolve this issue offline, I am closing this thread. If you have any further questions feel free to post your question here.

Best Regards,

Rahul