Application examples of single-rate FIRs operating at decimated rates

Hello comp.dsp,
I am writing an app-note and am looking for a real-world (or realistic) 
application to use.

I would be most grateful if anyone could up with real-world applications 
(ideally in the field of digital comms but does not have to be) for 
*single-rate* FIRs with the following *ideal* constraints:

- maximum rate in the system "Sr" ideally in the range 100-150MHz

- filter length N between say 15 to 60

- filter input bit-width between 1 and say 16 (signed or unsigned)

- the filter operates in the middle of a datapath where the sampling rate of 
the filter is less than or equal to Sr/N MHz (and such that there are blocks 
in the path before and/or after the filter that process samples at any 
integer division (including 1) of Sr

- filter coefficient bit-width between say 6 and 16

I know that in digital comms that filtering is usually only done with a 
rate-change (hence a deci/interp filter) to eliminate unwanted spectrum and 
avoid aliasing. But, I am hopeful that an application exists for single-rate 
FIRs...

I have quite a lot of experience in the hardware implementation of 
single-rate, interpolation and decimation filters but not so much in 
when/how people would want to apply them - hence the post! If someone knows 
of a datasheet or similar that would suit my purpose that would be ideal (as 
would a realistic non real-world example).

Many thanks in advance for your time,

Ken

PS  If my constraints need expanded then please let me know and I will do my 
best!  :-)

Hi Ken,

I don't know about anyone else around here, but I don't know what you
mean by "single-rate FIRs operating at decimated rates." If you mean
just a plain, simple FIR that is operating on decimated data, then why
would the fact that it is operating on decimated data have any
relevence?
-- 
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124

> I don't know about anyone else around here, but I don't know what you
> mean by "single-rate FIRs operating at decimated rates." If you mean
> just a plain, simple FIR that is operating on decimated data, then why
> would the fact that it is operating on decimated data have any
> relevence?

Hi Randy,

Thanks for the reply.

I do indeed mean a "plain, simple FIR that is operating on decimated data". 
The reason that it is operating on decimated data is relevant is because 
that means that there are "spare" clock cycles per output sample of the FIR 
available from one or more clock enable domains in the system.  This is 
crucial to allow flexibility of the hardware implementation.

e.g. if the system rate is 100MHz and the filter sampling rate is 10MHz and 
the filter has 10 taps, I can use 10 multipliers in parallel (assuming 
asymmetric impulse response) running at a clock enabled 10MHz or, if a 
100MHz clock is available, I can use 1 multiplier over 10 clock cycles and 
share the hardware.

Hence my constraint that it is operating on decimated data.

Hope that clears things up!  :-)

Cheers,

Ken

Ken wrote:

  ...

> Hope that clears things up!  :-)

Not for me. I see how the data rate being slower than the clock
simplifies the design, but what effect does the data's having been
decimated (rather than merely being sampled more slowly) have?

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

"Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message 
news:cmtf84$ap6$02$1@news.t-online.com...
>>> Hope that clears things up!  :-)
>>
>> Not for me. I see how the data rate being slower than the clock
>> simplifies the design, but what effect does the data's having been
>> decimated (rather than merely being sampled more slowly) have?
>
> Hi Jerry,
>
> You are absolutely correct - it does not really matter if the data has 
> been decimated or if it has just been sampled more slowly.
>
> All that matters is that the samples are at a lower rate than the system 
> rate according to my constraints.
>
> I guess I used "decimated" as that is typically how samples would end up 
> at a lower rate in a comms system...


Ken,

It seems to me that you'd benefit by compartmenting the problem.
It is just a FIR - no embellishments.
Implementation of that FIR in a particular hardware / software environment 
is your interest.
So, if I understand your question, you'd like to know how people have 
implemented relatively high-speed FIRs??  (It sounds like the application is 
clear enough for you).

One approach that's been used is to eliminate multiplications altogether by 
replacing them with shifts and adds.  For short FIRs this works pretty 
well - as the filter coefficients are approximated with sums of powers of 2. 
Longer filters would be tougher because of the precision necessary to 
effectively represent the coefficients of a longer filter.  But, you might 
find a way to usefully quantize the coefficients using this method - through 
some optimization scheme.  Of course, in an FPGA the shifts are "free" and 
the latency of the filter is determined by the number of addition stages 
used  ..... well, I think that's a good way to describe it.

Fred

>> Hope that clears things up!  :-)
>
> Not for me. I see how the data rate being slower than the clock
> simplifies the design, but what effect does the data's having been
> decimated (rather than merely being sampled more slowly) have?

Hi Jerry,

You are absolutely correct - it does not really matter if the data has been 
decimated or if it has just been sampled more slowly.

All that matters is that the samples are at a lower rate than the system 
rate according to my constraints.

I guess I used "decimated" as that is typically how samples would end up at 
a lower rate in a comms system...

Cheers,

Ken

"Clay Turner" <physics@bellsouth.net> wrote in message 
news:oQrkd.3911$jE2.1060@bignews4.bellsouth.net...
>
> "Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
> news:SqidnfGUQbW61Q_cRVn-jA@centurytel.net...
>>
>>
>> One approach that's been used is to eliminate multiplications altogether
> by
>> replacing them with shifts and adds.  For short FIRs this works pretty
>> well - as the filter coefficients are approximated with sums of powers of
> 2.
>> Longer filters would be tougher because of the precision necessary to
>> effectively represent the coefficients of a longer filter.  But, you 
>> might
>> find a way to usefully quantize the coefficients using this method -
> through
>> some optimization scheme.  Of course, in an FPGA the shifts are "free" 
>> and
>> the latency of the filter is determined by the number of addition stages
>> used  ..... well, I think that's a good way to describe it.
>>
>> Fred
>>
>
> Hello Fred,
>
> I saw a paper a few years back that worked with filter coefs restricted to
> powers of two. Also some work was done with using coefs that have only a 
> few
> nonzero bits, so the mults require few adders. Maybe you have seen some of
> these.
>
> Clay

Clay,

Right, there are some papers that discuss various approaches to optimizing 
the coefficients with this type of implementation in mind.  Alan Willson at 
UCLA was a contributor and Yong Ching Lim has published a number of papers. 
One difficulty of these approaches is that they are very compute intense if 
one is to find the optimum solution by exhaustive search - even if the 
search is "smart" there are lots of possible combinations.

As I recall, one method would optimize with a given number of bits. 
Willson's method had more to do with the cost of "hardware" with less than 
optimum frequency response .... something like that.  Maybe that's the one 
you're referring to.  I don't recall one quite like the one you describe .. 
but it's been some time since I was researching the topic.

Fred 

"Fred Marshall" <fmarshallx@remove_the_x.acm.org> wrote in message
news:SqidnfGUQbW61Q_cRVn-jA@centurytel.net...
>
>
> One approach that's been used is to eliminate multiplications altogether
by
> replacing them with shifts and adds.  For short FIRs this works pretty
> well - as the filter coefficients are approximated with sums of powers of
2.
> Longer filters would be tougher because of the precision necessary to
> effectively represent the coefficients of a longer filter.  But, you might
> find a way to usefully quantize the coefficients using this method -
through
> some optimization scheme.  Of course, in an FPGA the shifts are "free" and
> the latency of the filter is determined by the number of addition stages
> used  ..... well, I think that's a good way to describe it.
>
> Fred
>

Hello Fred,

I saw a paper a few years back that worked with filter coefs restricted to
powers of two. Also some work was done with using coefs that have only a few
nonzero bits, so the mults require few adders. Maybe you have seen some of
these.

Clay

"Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message
news:cmtf84$ap6$02$1@news.t-online.com...
> >> Hope that clears things up!  :-)
> >
> > Not for me. I see how the data rate being slower than the clock
> > simplifies the design, but what effect does the data's having been
> > decimated (rather than merely being sampled more slowly) have?
>
> Hi Jerry,
>
> You are absolutely correct - it does not really matter if the data has
been
> decimated or if it has just been sampled more slowly.
>
> All that matters is that the samples are at a lower rate than the system
> rate according to my constraints.
>
> I guess I used "decimated" as that is typically how samples would end up
at
> a lower rate in a comms system...

I think you are combining to separate entities together and that is causing
some confusion.
From your filter design standpoint (hardware), all that matters to you is
the clock which can be independent of the system sample rate. So in a comms
system, you could have an input sample rate of 100 MHz, but you can drive
the clock that feeds the FPGA (or other chip) that processes these samples
at 300 MHz. What is important to your multiplier plan/usage is the 300 MHz
clock. Yes - the fact that the data is coming in at 100 MHz or 10 MHz is
also important but it seems like you are tying the two aspects together.
Your design really shouldn't be dependent on whether the data is decimated
or not but should be dependent on what the input data sample rate is and
what kind of clock you get to use in your device.

Cheers
Bhaskar





>
> Cheers,
>
> Ken
>
>
>
>
>

Hi Fred,

Thanks for the reply.

> It seems to me that you'd benefit by compartmenting the problem.
> It is just a FIR - no embellishments.
> Implementation of that FIR in a particular hardware / software environment 
> is your interest.
> So, if I understand your question, you'd like to know how people have 
> implemented relatively high-speed FIRs??  (It sounds like the application 
> is clear enough for you).

I think the question from my original post is getting a little lost here.  I 
am just looking for a real-world application example (i.e. a datasheet for a 
suitable system or params of a suitable system that someone knows of) of 
single-rate FIRs that fits the contraints of my original post.


>
> One approach that's been used is to eliminate multiplications altogether 
> by replacing them with shifts and adds.  For short FIRs this works pretty 
> well - as the filter coefficients are approximated with sums of powers of 
> 2. Longer filters would be tougher because of the precision necessary to 
> effectively represent the coefficients of a longer filter.  But, you might 
> find a way to usefully quantize the coefficients using this method - 
> through some optimization scheme.  Of course, in an FPGA the shifts are 
> "free" and the latency of the filter is determined by the number of 
> addition stages used  ..... well, I think that's a good way to describe 
> it.

Coincidentally (or not!?), I have recently graduated with a PhD in this very 
topic!  Hence I am *very* familiar with the various methods of implementing 
FIRs on hardware.

What I am not so familiar with is the real-world application.  I am writing 
an app-note and I need it to be relevant to industry.

Cheers,

Ken