FIR filter in FPGA

[Mook Johnson]

I'm looking to implement four, 150 tap FIR filters in an Actel MX series
FPGA. The filters I'm designing are 16 bit input, 16 bit coeffienencs, and
1khz sample rate. FPGA will be clocked with a 10MHz clock and will have a
state machine to retrieve the samples from the A2D following a 1khz
interrupt.

How do I estimate the resource requirements to implement such a beast? Any
special hurdles in implelenting this type of thing in a Actel MX series
FPGA?

MX series is a fixed quantity and cannot be changed.

thanks

 

[Bob]

"Mook Johnson" <mook@mook.net> wrote in message
news:v86Yd.61130$SE2.59827@fe2.texas.rr.com...

I'm looking to implement four, 150 tap FIR filters in an Actel MX series
FPGA. The filters I'm designing are 16 bit input, 16 bit coeffienencs,
and
1khz sample rate. FPGA will be clocked with a 10MHz clock and will have a
state machine to retrieve the samples from the A2D following a 1khz
interrupt.

How do I estimate the resource requirements to implement such a beast?
Any
special hurdles in implelenting this type of thing in a Actel MX series
FPGA?

MX series is a fixed quantity and cannot be changed.

thanks

Post this over in comp.arch.fpga and you'll get lots of responses.

Bob

 

[Nico Coesel]

"Mook Johnson" <mook@mook.net> wrote:

I'm looking to implement four, 150 tap FIR filters in an Actel MX series
FPGA. The filters I'm designing are 16 bit input, 16 bit coeffienencs, and
1khz sample rate. FPGA will be clocked with a 10MHz clock and will have a
state machine to retrieve the samples from the A2D following a 1khz
interrupt.

You'll have to do 150k multiplies and 150k adds per second for each
channel. Each multiply will take 16 adds when implemented in a
bit-shift-add construction. This roughly means 2.6 million additions
per second for each channel.

How do I estimate the resource requirements to implement such a beast? Any
special hurdles in implelenting this type of thing in a Actel MX series
FPGA?

Looking at the MX specs, implementing this in an iterative process
shouldn't be a problem at all. Create an adder large enough to hold
the worst case value and start adding. Have the coefficients and
samples in SRAM (samples in a circular buffer) and create a state
machine which processes each input sample. Use dirty 2s complement.
Not adding 1 when converting from linear to signed saves logic and
you'll truncate those bits anyway.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

[Ken Smith]

In article <42319ad9.227569908@news.planet.nl>,
Nico Coesel <nico@puntnl.niks> wrote:
[...]

You'll have to do 150k multiplies and 150k adds per second for each
channel. Each multiply will take 16 adds when implemented in a
bit-shift-add construction. This roughly means 2.6 million additions
per second for each channel.

This is a bit of an over estimate. It assumes that the multiplies are
done with general purpose multipliers. You can usually arrange matters so
that you take advantage of the fact that many of the coef. values have
less than 1/2 the bits set.

--
--
kensmith@rahul.net forging knowledge

 

[Nico Coesel]

kensmith@green.rahul.net (Ken Smith) wrote:

In article <42319ad9.227569908@news.planet.nl>,
Nico Coesel <nico@puntnl.niks> wrote:
[...]
You'll have to do 150k multiplies and 150k adds per second for each
channel. Each multiply will take 16 adds when implemented in a
bit-shift-add construction. This roughly means 2.6 million additions
per second for each channel.

This is a bit of an over estimate. It assumes that the multiplies are
done with general purpose multipliers. You can usually arrange matters so
that you take advantage of the fact that many of the coef. values have
less than 1/2 the bits set.

Depending on the coefficients, you can save time with a smarter
multiplier indeed. On the other hand, this could create a problem if a
certain set of coefficients uses more time than the design allows.

Anyway, another thought on the problem of the OP: Why use a FIR
filter? An IIR filter is much more convenient to implement because it
needs less temporary storage and multiplications.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

Mook,

As I know, unfortunately you cannot assess the resource utilization
unless you code your design, synthesize, map, PAR using Actel tools.
Any reason why you are going for MX FPGAs?

The datasheet of MX says :
"The MX device architecture is based on Actel's patented antifuse
technology implemented in a 0.45ľm triplemetal CMOS process."

That means they are not reprogrammable. I am not really into DSP, but
have found that Altera and Xilinx have the best resources to implement
DSP algorithms.

 

[Nico Coesel]

sams235@gmail.com wrote:

Mook,

That means they are not reprogrammable. I am not really into DSP, but
have found that Altera and Xilinx have the best resources to implement
DSP algorithms.

This depends highly on the type of FPGA you are using. I don't know
about Altera, but Xilinx is quite agressive in marketing their
products as DSP replacements which is not always true. If you want to
implement some serious signal processing you'll need on-chip
multipliers which are only available in the newer Xilinx series (like
Spartan 3). On a cheap FPGA without hardware multipliers you can get
about 8 to 20 MMACs based on 16 bit words per multiplier. A hardware
multiplier can be up to 10 times faster.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

[Fabio G.]

nico@puntnl.niks (Nico Coesel) ha scritto:

Not adding 1 when converting from linear to signed saves logic and
you'll truncate those bits anyway.

Can you explain better this point?

--
Per rispondermi via email sostituisci il risultato
dell'operazione (in lettere) dall'indirizzo

 

[Nico Coesel]

Fabio G. <7+5@supereva.it> wrote:

nico@puntnl.niks (Nico Coesel) ha scritto:

Not adding 1 when converting from linear to signed saves logic and
you'll truncate those bits anyway.

Can you explain better this point?

If you implement signal processing in an FPGA you'll often find
yourself converting from one number representation to the other.
It is easier to multiply sign magnitude numbers (and handle the sign
with an XOR port) than a 2s complement number. When it comes to
adding, it is easier to work with 2s complement.
When converting from sign-magnitude to 2s complement (and vice versa)
you should add 1 to the conversion result -officially-. This does take
extra logic, in the worst case an extra adder.
In reality you'll lose some bits due to rounding filtering results
anyway so not adding 1 during conversions is something you won't
notice in the result.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

 

[tlbs]

Anti-fuse tech. is inherently rad-hard for space use. That's usually
why someone picks Actel (that's why I do, anyway).

Although... Xilinx flew to, and is currently roving on Mars -- those
designers used some special tricks to "up" the rad-hardness of those
designs: redundant chips and TRM gates. I have read things that makes
me believe JPL has to re-load the Xilinx FPGA's on the rovers more than
once per day.

As for the FIR design, the larger of the MX series should work just
fine for your design.

 

Although... Xilinx flew to, and is currently roving on Mars -- those
designers used some special tricks to "up" the rad-hardness of those
designs: redundant chips and TRM gates. I have read things that makes
me believe JPL has to re-load the Xilinx FPGA's on the rovers more
than
once per day.

Using Xilinx with these "tricks" offers more number of advantages. In
this age where the performance and reliability of software algorithms
is changing every day, you would want something that could be updated
anytime you want without changing the hardware (which ofcourse is not
possible with anti fuse FPGA).

As far as the reliability of these "tricks" is concerned, TMR with many
other features can be used for effective radiation tolerance. The area
however is more, but considering the use of TMR antifuse latches in
Actel's FPGAs, this area is not overwhelmingly higher.