Newbie needs help optimizing quantized FIR LPF coefficients

On Tue, 26 Oct 2004 06:32:50 -0700, Tim Wescott
<tim@wescottnospamdesign.com> wrote:

>Tony wrote:
>
>> Hi,
>> 
>> I want to implement a speed-critical FIR LPF (order about 50-60) in a
>> 16bit MCU (MSP430), but it's MAC accumulator is only 32 bits, so it
>> could overflow with bad results if I don't scale down the coefficients
>> so the peak value is about 7000 (decimal). I've installed SciLab
>> hoping to find a way to optimize the coefficients, but I can't find
>> anything in Signals that directly relates. Is there a toolbox, or some
>> SciLab code somewhere, or MatLab code I could convert? Or some other
>> place to get a clue?
>> 
>> Tony (remove the "_" to reply by email)
>
>The MSP430 hardware multiplier includes a sum extend register that 
>extends the accumulator to 48 bits, so you should be able to do a 16-bit 
>FIR with tens of thousands of taps without overflow.  See 
>http://focus.ti.com/lit/an/slaa042/slaa042.pdf for details.

That method didn't even occur to me - I was using the MACS operation,
which isn't easily extended past a 32bit result, but now I can see
that by doing the accumulation separately there's no limitation
(although it is a lot slower). More thinking needed when I get to
work. Thanks.

Tony (remove the "_" to reply by email)

On Tue, 26 Oct 2004 10:59:02 -0700, "Fred Marshall"
<fmarshallx@remove_the_x.acm.org> wrote:

>
>"Tony" <tony_roe@tpg.com.au> wrote in message 
>news:u84sn01nced6u122qkapassmf8o85evmku@4ax.com...
>> Hi,
>>
>> I want to implement a speed-critical FIR LPF (order about 50-60) in a
>> 16bit MCU (MSP430), but it's MAC accumulator is only 32 bits, so it
>> could overflow with bad results if I don't scale down the coefficients
>> so the peak value is about 7000 (decimal). I've installed SciLab
>> hoping to find a way to optimize the coefficients, but I can't find
>> anything in Signals that directly relates. Is there a toolbox, or some
>> SciLab code somewhere, or MatLab code I could convert? Or some other
>> place to get a clue?
>
>I don't know if this addresses your situation, but it may.  It depends on 
>the DSP:
>Some FIR implementations, particularly in FPGAs, attempt to reduce the 
>number of multiplies by replacing them with shifts and adds.  So, what's 
>done is to replace the coefficients with sums of powers of 2 - effectively 
>truncating the coefficients to a small number of bits.  Of course, the 
>shifts are done in the "wiring" so add no operational load - so it's a 
>matter of whether adds are "cheaper" in some way than multiplies.
>
>0.625 would be a perfect case: 0.5 + 0.125, etc.
>
>So, you attempt to find the "best" result for quantized coefficients over 
>the universe of possible coefficient values - truncated to some number of 
>bits.
>
>There's a lot of literature and there are some discussions in comp.dsp about 
>this approach.
>
>Fred 

Yes they are good things to think about, although in this case, the
MCU has a full (albeit slow to loop) MAC unit, which allows the
coefficients to be more arbitrary, although they still suffer from
errors due to truncation noise.

Tony (remove the "_" to reply by email)

Steve,

What you have written below is a too often seen misconception. It is
possible that removing a frequency with a unity gain passband lowpass
filter can increase the signal range.

Example: Consider a signal composed of the 1st and 3rd harmonics of a
square wave.  Scale the peak of the signal to 1.0.  A unity gain
lowpass can remove the 3rd harmonic, leaving the 1st harmonic, with
the result that the peak is now increased above 1.0.

Dirk



Steve Underwood <steveu@dis.org> wrote in message 

<snipped>

As long as the overall gain of your 
> filter does not exceed one at any frequency, the final result will be 
> OK. If you are using a filter design tool, it most probably draws a 
> frequency response plot for you. It should be easy to see from that if 
> your filter meets the unity gain criteria. If not, scale everything down 
> until is does. 

<snipped>

http://www.winfilter.20m.com (freeware) has 8-bit, 16-bit or float coef 
quantization and produce C or VHDL code.

Adrian

Tony wrote:

> Hi,
> 
> I want to implement a speed-critical FIR LPF (order about 50-60) in a
> 16bit MCU (MSP430), but it's MAC accumulator is only 32 bits, so it
> could overflow with bad results if I don't scale down the coefficients
> so the peak value is about 7000 (decimal). I've installed SciLab
> hoping to find a way to optimize the coefficients, but I can't find
> anything in Signals that directly relates. Is there a toolbox, or some
> SciLab code somewhere, or MatLab code I could convert? Or some other
> place to get a clue?
> 
> Tony (remove the "_" to reply by email)



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Thanks Adrian - it looks like a nice tool, but I already have a number
of options to generate the coefficients (even outside SciLab). It's
finding/minimizing the effect of OTHER arbitrary quantizations that
I'm after.

On Wed, 27 Oct 2004 08:13:17 +0200, Adrian <adrian@nospam.com> wrote:
>http://www.winfilter.20m.com (freeware) has 8-bit, 16-bit or float coef 
>quantization and produce C or VHDL code.
>
>Adrian
>
>Tony wrote:
>
>> Hi,
>> 
>> I want to implement a speed-critical FIR LPF (order about 50-60) in a
>> 16bit MCU (MSP430), but it's MAC accumulator is only 32 bits, so it
>> could overflow with bad results if I don't scale down the coefficients
>> so the peak value is about 7000 (decimal). I've installed SciLab
>> hoping to find a way to optimize the coefficients, but I can't find
>> anything in Signals that directly relates. Is there a toolbox, or some
>> SciLab code somewhere, or MatLab code I could convert? Or some other
>> place to get a clue?
>> 
>> Tony (remove the "_" to reply by email)
>
>
>
>----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
>http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
>---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Tony (remove the "_" to reply by email)

Thanks to all who helped out. I got the hang of SciLab (great prog,
especially for the price), and it appears my fears were generally
unfounded; even with quite heavy quantizing, the peaks in the
stop-band only seemed to come up very marginally.

Tony (remove the "_" to reply by email)

Tim Wescott wrote:

> Tony wrote:
>
>> Hi,
>>
>> I want to implement a speed-critical FIR LPF (order about 50-60) in a
>> 16bit MCU (MSP430), but it's MAC accumulator is only 32 bits, so it
>> could overflow with bad results if I don't scale down the coefficients
>> so the peak value is about 7000 (decimal). I've installed SciLab
>> hoping to find a way to optimize the coefficients, but I can't find
>> anything in Signals that directly relates. Is there a toolbox, or some
>> SciLab code somewhere, or MatLab code I could convert? Or some other
>> place to get a clue?
>>
>> Tony (remove the "_" to reply by email)
>
>
> The MSP430 hardware multiplier includes a sum extend register that 
> extends the accumulator to 48 bits, so you should be able to do a 
> 16-bit FIR with tens of thousands of taps without overflow.  See 
> http://focus.ti.com/lit/an/slaa042/slaa042.pdf for details.

The extension register is only ever 0 or 0xFFFF. It isn't really a 48 
bit sum. It just shows the status of the last calculation in the MAC.

Steve

Hi Dirk,

Quite true. I was a rather sloppy with what I said. I thought the 
original poster was worried about basic step by step overflow issues in 
calculating FIRs, and that's what I was trying to emphasise. It seems 
from a later posting he already appreciated that point.

Of course, what you describe is a fairly benign case, and much nastier 
peaks are possible. This is a dilemma you often face with FIRs, even on 
a DSP with some headroom bits. To saturate or not to saturate. That is 
the question. Whether 'tis nobler in the mind to face the slings and 
arrows of outrageous results, or to clip more often is absolutely 
necessary. In different situations either may be the more tolerable. I 
suspect the poster is probably working on some kind of control 
application, in which case banging the endstops (saturating) is the 
usually the better alternative. Sadly, his platform has no saturation 
logic, and if he must calculate quickly, he's stuck with the possibility 
of outrageous results :-(

Steve


Dirk A. Bell wrote:

>Steve,
>
>What you have written below is a too often seen misconception. It is
>possible that removing a frequency with a unity gain passband lowpass
>filter can increase the signal range.
>
>Example: Consider a signal composed of the 1st and 3rd harmonics of a
>square wave.  Scale the peak of the signal to 1.0.  A unity gain
>lowpass can remove the 3rd harmonic, leaving the 1st harmonic, with
>the result that the peak is now increased above 1.0.
>
>Dirk
>
>
>
>Steve Underwood <steveu@dis.org> wrote in message 
>
><snipped>
>
>As long as the overall gain of your 
>  
>
>>filter does not exceed one at any frequency, the final result will be 
>>OK. If you are using a filter design tool, it most probably draws a 
>>frequency response plot for you. It should be easy to see from that if 
>>your filter meets the unity gain criteria. If not, scale everything down 
>>until is does. 
>>    
>>
>
><snipped>
>  
>