IIR filter coefficients in iircas5 dsplib

Hi,
I have a problem trying to implement an IIR filter with iircas5 function on an TI c55x. I have calculated the filter coefficients with matlab. My designed filter with MATLAB show 40dB attenation of input signal at 2000Hz while it is approximately 15dB in CCS with iircas5.

Thanks. Start a New Thread

S Dabbaghchian-

> I have a problem trying to implement an IIR filter with iircas5
> function on an TI c55x. I have calculated the filter
> coefficients with matlab. My designed filter with MATLAB show
> 40dB attenation of input signal at 2000Hz while it is
> approximately 15dB in CCS with iircas5.

Your question is general without specific problem definition...

What are the filter parameters: what IIR design method, what Fs, Fc, ripple?

Are your MATLAB filter coefficients fixed-point? If not, then how did you convert to fixed-point required by iircas5?
If yes, then what method did you use in MATLAB to verify the fixed-point implementation will be stable? And in both
cases, what Q-notation are you using?

-Jeff Start a New Thread

Saeed-

> Dear Jeff, Thanks for attention> I am using fdatool of MATLAB to design a lowpass
IIR filter
> with following specification:> Fs00, Fc00, Butterworth, order=6, Direct-Form
II,
> second order sections.
> I generate quantized coefficients from Targets\Generate C
> header menu. fdatool in quantization parameters suggest
> the best Q which is 13 for numerator and 14 for denumerator
> in my example.
> Although iircas5 get Q15 but when I change the Q in fdatool,
> the filter response change to undesirable shape.

Well, if fdatool suggests Q-13 and Q-14 for numerator and denominator coefficients,
then it has a good reason. Those are probably minimum values that allow stable
filter output.

My suggestions as follows:

1) First, try Q-14 for both num and denom in fdatool, does it still work? The reason
to check this is because iircas5 isn't going to split Q-notation between num and
denom (i.e. dsplib asm code is not that sophisticated). If Q-14 works, then try Q-15
also. Note that increasing Q-notation, even though improving coefficient precision,
may cause an overflow problem, so it's not at all guaranteed that "more is better".

2) Study iircas5 asm source code carefully. If Q-15 worked in fdatool, then you
might be able to use iircas5 as-is. If not, for example you have to use Q-14, then
you will need to change iircas5 code -- typically this involves changing shift values
in several places.

-Jeff
PS. Please post to the group, not to me. The operative word in Yahoo Group is
"group".
--- On Mon, 7/27/09, Jeff Brower wrote:
From: Jeff Brower
Subject: Re: [c55x] IIR filter coefficients in iircas5 dsplib
To: s...@yahoo.com
Cc: c...
Date: Monday, July 27, 2009, 1:22 PM

S Dabbaghchian-

> I have a problem trying to implement an IIR filter with iircas5
> function on an TI c55x. I have calculated the filter
> coefficients with matlab. My designed filter with MATLAB show
> 40dB attenation of input signal at 2000Hz while it is
> approximately 15dB in CCS with iircas5.

Your question is general without specific problem definition...

What are the filter parameters: what IIR design method, what Fs, Fc,
ripple?

Are your MATLAB filter coefficients fixed-point? If not, then how did you
convert to fixed-point required by iircas5?
If yes, then what method did you use in MATLAB to verify the fixed-point
implementation will be stable? And in both
cases, what Q-notation are you using?

-Jeff Start a New Thread

On Jul 29, 2009, at 14:20, Jeff Brower wrote:
> > I generate quantized coefficients from Targets\Generate C
>
> > header menu. fdatool in quantization parameters suggest
> > the best Q which is 13 for numerator and 14 for denumerator
> > in my example.
> > Although iircas5 get Q15 but when I change the Q in fdatool,
> > the filter response change to undesirable shape.
>
> Well, if fdatool suggests Q-13 and Q-14 for numerator and
> denominator coefficients, then it has a good reason. Those are
> probably minimum values that allow stable filter output.
>
> My suggestions as follows:
>
> 1) First, try Q-14 for both num and denom in fdatool, does it still
> work? The reason to check this is because iircas5 isn't going to
> split Q-notation between num and denom (i.e. dsplib asm code is not
> that sophisticated). If Q-14 works, then try Q-15 also. Note that
> increasing Q-notation, even though improving coefficient precision,
> may cause an overflow problem, so it's not at all guaranteed that
> "more is better".
>

Forgive my question, but isn't the numerator specification supposed
to allow for overflow? I would think that the single determining
factor in calculating the minimum numerator bits is specifically to
avoid overflow. The denominator is for precision and to reduce
quantization noise. Am I overlooking something?

Obviously, you cannot exceed the register size, so the Q total for
numerator and denominator together cannot be too high.

Brian Start a New Thread

Hey Brian-

> On Jul 29, 2009, at 14:20, Jeff Brower wrote:
>> > I generate quantized coefficients from Targets\Generate C
>>
>> > header menu. fdatool in quantization parameters suggest
>> > the best Q which is 13 for numerator and 14 for denumerator
>> > in my example.
>> > Although iircas5 get Q15 but when I change the Q in fdatool,
>> > the filter response change to undesirable shape.
>>
>> Well, if fdatool suggests Q-13 and Q-14 for numerator and
>> denominator coefficients, then it has a good reason. Those are
>> probably minimum values that allow stable filter output.
>>
>> My suggestions as follows:
>>
>> 1) First, try Q-14 for both num and denom in fdatool, does it still
>> work? The reason to check this is because iircas5 isn't going to
>> split Q-notation between num and denom (i.e. dsplib asm code is not
>> that sophisticated). If Q-14 works, then try Q-15 also. Note that
>> increasing Q-notation, even though improving coefficient precision,
>> may cause an overflow problem, so it's not at all guaranteed that
>> "more is better".
>> Forgive my question, but isn't the numerator specification supposed
> to allow for overflow? I would think that the single determining
> factor in calculating the minimum numerator bits is specifically to
> avoid overflow.

In that case, what would be the difference between just reducing input; i.e. cutting off some bits before the filter?

If fdatool is like other fixed-point filter simulation programs I've seen it would run iteratively, attempting to find
a combination of input bit-length and filter coefficient quantization that yields optimized results. If it says Q13
is good for numerator coeffs, then I'm assuming it found a reason other than just shifting each input sample right by
2 bits and it still wants input in Q-15 notation. But you make a good point, maybe all it's saying is hack the input.
I don't know enough about fdatool.

> The denominator is for precision and to reduce
> quantization noise. Am I overlooking something?

In my experience, IIR implementations often take some trial and error to find a balance. Make intermediate stage
input too small and precision / stability / noise issues are magnified.

> Obviously, you cannot exceed the register size, so the Q total for
> numerator and denominator together cannot be too high.

Yes... one of the reasons why in 16-bit audio systems people often end up using Q-32 or higher for fixed-point IIR
filters coefficients.

But I have to say I've never seen summing num + denom Q-notations give guidance. The thing boils down to what the
filter does in transition regions, where greatest dynamic range is required. By the time the last biquad cascade
section is reached, depending on what the input is doing, a lot of extra bits might be needed. Reducing input
Q-notation to get there is like an "uncertainty principle" -- it changes the very nature of the thing you're trying to
fix.

-Jeff Start a New Thread

Brian-

>> Hey Brian-
>>> Forgive my question, but isn't the numerator specification supposed
>>> to allow for overflow? I would think that the single determining
>>> factor in calculating the minimum numerator bits is specifically to
>>> avoid overflow.
>>
>> In that case, what would be the difference between just reducing
>> input; i.e. cutting off some bits before the filter?
>
> That would involve loss of input resolution, and certainly should be
> avoided except as a last option after exhausting all others, e.g. if
> you hit your maximum register size.

My point is that multiplying all numerator coefficients by 1/4 to change them from Q15 to Q13 is mathematically the
same as multipying every input value by 1/4 prior to filtering. The end filter result should be the same.

But, we know that factoring the transfer response into biquad cascade sections can create stages with varying
sensitivity to quantization errors, and introduce small -- but cumulative -- differences that cause actual results to
not line up with overall transfer response math. I don't know about fdatool, but I've seen IIR fixed-point filter
programs that "try harder", for example creating a coding implementation does some intermediate stage-specific things,
like using a higher Q-notation locally in a stage, then scaling that output as needed for the next stage. These
techniques trade performance for filter stability and high SNR... a typical tradeoff. This is why I'm trying to give
fdatool the benefit of the doubt.

>> If fdatool is like other fixed-point filter simulation programs
>> I've seen it would run iteratively, attempting to find a
>> combination of input bit-length and filter coefficient quantization
>> that yields optimized results. If it says Q13 is good for
>> numerator coeffs, then I'm assuming it found a reason other than
>> just shifting each input sample right by 2 bits and it still wants
>> input in Q-15 notation. But you make a good point, maybe all it's
>> saying is hack the input. I don't know enough about fdatool.
>
> I have only tried once to create my own fixed-point optimization. In
> that case, it was Taylor series expansion for logarithm and
> exponent. What I did was use floating point to run through all the
> calculations, keeping a log of maximum intermediate values.
> Regardless of the fact that my input would always be between 0.0 and
> < 1.0, there were still intermediate values as high as, say, 26.0,
> thus requiring at least 5 bits in the whole number part, which I
> initially assumed is the "numerator" that was referred to (and now I
> realize I probably have the terminology wrong).
>
> In other words, reducing input resolution will not help keep
> intermediate values from overflowing. There is a wide discrepancy
> between +/- 1.0 or less on input, and the much larger intermediate
> values.

That is not correct. Reducing input values sometimes can be helpful; in the OP's example, "helpful" would seem to
mean avoiding values more than Q15. A lot depends on how sensitive is the filter. But even if it does work, the end
result would have less SNR, which may not be acceptable, depending on the application.

-Jeff

>>> The denominator is for precision and to reduce
>>> quantization noise. Am I overlooking something?
>>
>> In my experience, IIR implementations often take some trial and
>> error to find a balance. Make intermediate stage input too small
>> and precision / stability / noise issues are magnified.
> Certainly.
>>>> Obviously, you cannot exceed the register size, so the Q total for
>>>> numerator and denominator together cannot be too high.
>>>
>>> Yes... one of the reasons why in 16-bit audio systems people often
>>> end up using Q-32 or higher for fixed-point IIR
>>> filters coefficients.
>>
>> But I have to say I've never seen summing num + denom Q-notations
>> give guidance. The thing boils down to what the filter does in
>> transition regions, where greatest dynamic range is required. By
>> the time the last biquad cascade section is reached, depending on
>> what the input is doing, a lot of extra bits might be needed.
>> Reducing input Q-notation to get there is like an "uncertainty
>> principle" -- it changes the very nature of the thing you're trying
>> to fix.
>
> It seems that I spoke too soon, without reviewing the various Q-
> notation standards. For some reason, I briefly thought that the dual
> figures of Q-13 and Q-14 for numerator and denominator were talking
> about whole integer bits and fractional bits. In hindsight, that was
> a strange assumption on my part!
>
> After reviewing the Wikipedia entry for Fixed point, I find that I
> prefer the unambiguous form of the "Q" notation, e.g. Q3.13 and Q2.14
> for numerator and denominator.
>
> In the Taylor series mentioned above, I did find it useful to use
> different points for different values of the calculation, so now it
> makes sense that a filter would have more than one fixed point format
> internally.
>
> Now I'm thinking that you can't just use Q2.14 when fdatool suggests
> Q3.13 and Q2.14, because Q2.14 overflows faster. You almost might
> have better luck starting with Q3.13 if your code can't handle split
> Q-notation. Obviously, don't take my word for it, but try both.
>
> Brian Start a New Thread