FIR FIlter

Hallo 
Can I get the VHDL code for FIR Filter designing or please get me the idea
to write it.
swarna

It's not difficult to write yourself. You need four things:
- A shift register
- Multiply/accumulate (MAC) at each stage
- A rom/ram for the coefficients
- Fixed point math in the MAC blocks

This may not be the most ideal architecture, but it's probably
conceptually easiest. Figuring out the fixed point math is probably
the hardest thing. Don't forget that each subsequent MAC will need to
be larger to keep the full precision of the math. It's up to you to
figure out if you want to limit precision at each stage, limit it at
the end or just have a really big output.

Having an FPGA with built in multipliers/DSP blocks helps otherwise
the whole thing will be slow for a reasonable input width.


On Oct 31, 12:44 pm, "swarnahans" <swarnah...@yahoo.co.in> wrote:
> Hallo
> Can I get the VHDL code for FIR Filter designing or please get me the idea
> to write it.
> swarna

Chris Maryan wrote:

> It's not difficult to write yourself. You need four things:
> - A shift register
> - Multiply/accumulate (MAC) at each stage
> - A rom/ram for the coefficients
> - Fixed point math in the MAC blocks
> 
> This may not be the most ideal architecture, but it's probably
> conceptually easiest. Figuring out the fixed point math is probably
> the hardest thing. Don't forget that each subsequent MAC will need to
> be larger to keep the full precision of the math. It's up to you to
> figure out if you want to limit precision at each stage, limit it at
> the end or just have a really big output.
> 
> Having an FPGA with built in multipliers/DSP blocks helps otherwise
> the whole thing will be slow for a reasonable input width.
> 
> 
> On Oct 31, 12:44 pm, "swarnahans" <swarnah...@yahoo.co.in> wrote:
> 
>>Hallo
>>Can I get the VHDL code for FIR Filter designing or please get me the idea
>>to write it.
>>swarna
> 
> 
> 


Frankly, floating point doesn't really make a lot of sense for an FIR 
filter, as the FIR filter is a sum of products.  In order to make the 
sum, all the products have to be denormalized to a common scale, which 
if you work through the analysis is the scale of the biggest product 
(which is generally the center tap(s) of an FIR filter.  Since the 
signal visits all taps in turn, there is nothing really to be gained by 
working with floating point.

On Oct 31, 4:14 pm, Ray Andraka <r...@andraka.com> wrote:
>
> Frankly, floating point doesn't really make a lot of sense for an FIR
> filter, as the FIR filter is a sum of products.  In order to make the
> sum, all the products have to be denormalized to a common scale, which
> if you work through the analysis is the scale of the biggest product
> (which is generally the center tap(s) of an FIR filter.  Since the
> signal visits all taps in turn, there is nothing really to be gained by
> working with floating point.

actually, i agree with you Ray, but maybe not for all the reasons.
floating-point coefs of h[n] can better represent little things like
the heavily attenuated stopband than fixed-point coefs.

i remember a sorta neat idea that i first heard from another AES
person, Duane Wise (now that i think of it, i co-authored a paper with
this guy once).  anyway this idea was presented with this paper:

http://www.aes.org/e-lib/browse.cfm?elib=9163 "Block Floating-Point
FIR Filters Using a Fixed-Point Multiplier"

don't bother getting (and paying for) the preprint, the idea was
pretty simple (but still clever and novel as far as i can tell).
assuming a symmetric and phase-linear FIR, he started his FIR
summation from the tails of h[n] (where the coefs are tiny) and worked
in toward the middle where the coefs are bigger.  the tiny
coefficients were scaled up by some known power of two and at the
known places (in h[n]) where the scaling constant was changed to 1/2
of what it had been, he would end the loop, arithmetic shift the
accumulator one bit to the right, and continue with the summation.
his stopband performance (which is degraded by coef quantization) was
*much* better.  it's a sorta block-floating point, but done with fixed-
point hardware.

r b-j

robert bristow-johnson wrote:
> On Oct 31, 4:14 pm, Ray Andraka <r...@andraka.com> wrote:
>> Frankly, floating point doesn't really make a lot of sense for an FIR
>> filter, as the FIR filter is a sum of products.  In order to make the
>> sum, all the products have to be denormalized to a common scale, which
>> if you work through the analysis is the scale of the biggest product
>> (which is generally the center tap(s) of an FIR filter.  Since the
>> signal visits all taps in turn, there is nothing really to be gained by
>> working with floating point.
> 
> actually, i agree with you Ray, but maybe not for all the reasons.
> floating-point coefs of h[n] can better represent little things like
> the heavily attenuated stopband than fixed-point coefs.
> 
> i remember a sorta neat idea that i first heard from another AES
> person, Duane Wise (now that i think of it, i co-authored a paper with
> this guy once).  anyway this idea was presented with this paper:
> 
> http://www.aes.org/e-lib/browse.cfm?elib=9163 "Block Floating-Point
> FIR Filters Using a Fixed-Point Multiplier"
> 
> don't bother getting (and paying for) the preprint, the idea was
> pretty simple (but still clever and novel as far as i can tell).
> assuming a symmetric and phase-linear FIR, he started his FIR
> summation from the tails of h[n] (where the coefs are tiny) and worked
> in toward the middle where the coefs are bigger.  the tiny
> coefficients were scaled up by some known power of two and at the
> known places (in h[n]) where the scaling constant was changed to 1/2
> of what it had been, he would end the loop, arithmetic shift the
> accumulator one bit to the right, and continue with the summation.
> his stopband performance (which is degraded by coef quantization) was
> *much* better.  it's a sorta block-floating point, but done with fixed-
> point hardware.
> 
> r b-j
> 
That strategy is far older than the paper you cited. I was taught that 
trick by a colleague in my first year working on DSP systems. That guy 
taught me a few neat tricks, and all by throw away lines rather than by 
serious teaching.

Steve

robert bristow-johnson wrote:

   ...

> *much* better.  it's a sorta block-floating point, but done with fixed-
> point hardware.

Isn't working with fixed-point hardware the whole point of block 
floating point?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Oct 31, 11:44 am, "swarnahans" <swarnah...@yahoo.co.in> wrote:
> Hallo
> Can I get the VHDL code for FIR Filter designing or please get me the idea
> to write it.
> swarna

Hi Swarna,

You must be new to filter design. How will you be generating your
coefficients?

Darol

Steve Underwood wrote:

   ...

> That strategy is far older than the paper you cited. I was taught that 
> trick by a colleague in my first year working on DSP systems. That guy 
> taught me a few neat tricks, and all by throw away lines rather than by 
> serious teaching.

A lot of good technique gets reinvented. FFT and fraction saving, to 
name just two.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

robert bristow-johnson wrote:
> On Oct 31, 4:14 pm, Ray Andraka <r...@andraka.com> wrote:
> 
>>Frankly, floating point doesn't really make a lot of sense for an FIR
>>filter, as the FIR filter is a sum of products.  In order to make the
>>sum, all the products have to be denormalized to a common scale, which
>>if you work through the analysis is the scale of the biggest product
>>(which is generally the center tap(s) of an FIR filter.  Since the
>>signal visits all taps in turn, there is nothing really to be gained by
>>working with floating point.
> 
> 
> actually, i agree with you Ray, but maybe not for all the reasons.
> floating-point coefs of h[n] can better represent little things like
> the heavily attenuated stopband than fixed-point coefs.
> 
> i remember a sorta neat idea that i first heard from another AES
> person, Duane Wise (now that i think of it, i co-authored a paper with
> this guy once).  anyway this idea was presented with this paper:
> 
> http://www.aes.org/e-lib/browse.cfm?elib=9163 "Block Floating-Point
> FIR Filters Using a Fixed-Point Multiplier"
> 
> don't bother getting (and paying for) the preprint, the idea was
> pretty simple (but still clever and novel as far as i can tell).
> assuming a symmetric and phase-linear FIR, he started his FIR
> summation from the tails of h[n] (where the coefs are tiny) and worked
> in toward the middle where the coefs are bigger.  the tiny
> coefficients were scaled up by some known power of two and at the
> known places (in h[n]) where the scaling constant was changed to 1/2
> of what it had been, he would end the loop, arithmetic shift the
> accumulator one bit to the right, and continue with the summation.
> his stopband performance (which is degraded by coef quantization) was
> *much* better.  it's a sorta block-floating point, but done with fixed-
> point hardware.
> 
> r b-j
> 


Yes, I've used this as well, but you don't need floating point to do it. 
  It is also a fixed point technique, as all the scaling is by fixed 
amounts depending on the coefficient.  The real advantage here is a 
hardware savings in that you'd get the same results by carrying the 
fixed point for the width that gets you the precision of those smallest 
coefficients, but you get to knock off redundant MSBs.

hi,

You can try this freeware (http://www.winfilter.20m.com). I hope that
is what you are looking for.
regards,
Adrian



On Oct 31, 5:44 pm, "swarnahans" <swarnah...@yahoo.co.in> wrote:
> Hallo
> Can I get the VHDL code for FIR Filter designing or please get me the idea
> to write it.
> swarna