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.

# IIR filter coefficients in iircas5 dsplib

Started by ●July 27, 2009

Reply by ●July 27, 20092009-07-27

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

> 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

Reply by ●July 29, 20092009-07-29

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

> 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

Reply by ●July 29, 20092009-07-29

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

> > 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

Reply by ●July 29, 20092009-07-29

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

> 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

Reply by ●July 29, 20092009-07-29

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

>> 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