FIR filter O/p width

[faz]

Hai,

Is there any formula or general rule to set output width of FIR filter
given its input ,coefficients width and number of taps.??

I red in some data sheet of FIR filter deisgn as:
output width = input width+coefficient width+logN(base 2)

In some other data sheet of FIR filter deisgn as:
output width = 2*input width+logN(base 2)

which of the above is correct??pls give some link for refernce doc
explaining the general rule to set o/p width..

regards,
faz

[bharat pathak]

>Is there any formula or general rule to set output width of FIR filter
>given its input ,coefficients width and number of taps.??

There is no such Formula.

>I red in some data sheet of FIR filter deisgn as:
>output width = input width+coefficient width+logN(base 2)
>
>In some other data sheet of FIR filter deisgn as:
>output width = 2*input width+logN(base 2)

Both the formula are incorrect and most probably u would
have read them in some FPGA white paper.

[faz]

On May 27, 5:39*pm, "bharat pathak" <[email protected]> wrote:
> >Is there any formula or general rule to set output width of FIR filter
> >given its input ,coefficients width and number of taps.??
>
> There is no such Formula.
>
> >I red in some data sheet of FIR filter deisgn as:
> >output width = input width+coefficient width+logN(base 2)
>
> >In some other data sheet *of FIR filter deisgn as:
> >output width = 2*input width+logN(base 2)
>
> Both the formula are incorrect and most probably u would
> have read them in some FPGA white paper.

Hai,

U cannot say it as incorrect because they are following some practical
consideration as given below..

http://personal.rdu.bellsouth.net/~yatesc/fir.pdf

pls go through the fixed point summation theorem in page 6..

All FPGA vendors like ALTERA,XILINX,ACTEL,ALDEC,LATTICE follow this
formula for their FIR filter design generation...so how it can be
incorrect...

Still u are not convinced...then justify why it is wrong??and explain
wat is the right way to calculate it??

regards,
faz

[Randy Yates]

faz <[email protected]> writes:

> On May 27, 5:39*pm, "bharat pathak" <[email protected]> wrote:
>> >Is there any formula or general rule to set output width of FIR filter
>> >given its input ,coefficients width and number of taps.??
>>
>> There is no such Formula.
>>
>> >I red in some data sheet of FIR filter deisgn as:
>> >output width = input width+coefficient width+logN(base 2)
>>
>> >In some other data sheet *of FIR filter deisgn as:
>> >output width = 2*input width+logN(base 2)
>>
>> Both the formula are incorrect and most probably u would
>> have read them in some FPGA white paper.
>
> Hai,
>
> U cannot say it as incorrect because they are following some practical
> consideration as given below..
>
> http://personal.rdu.bellsouth.net/~yatesc/fir.pdf

Hi Faz,

I can't believe that link still works! I haven't had my internet
service with Bellsouth for at least 3 years! (And that is an
old version of the paper.)

Please use the following link instead:

http://www.digitalsignallabs.com/fir.pdf
http://www.digitalsignallabs.com/fp.pdf

> Still u are not convinced...then justify why it is wrong??and explain
> wat is the right way to calculate it??

Faz, Bharat, if I have made an error, please let me know. I will
be watching this thread.
--
% Randy Yates % "Bird, on the wing,
%% Fuquay-Varina, NC % goes floating by
%%% 919-577-9882 % but there's a teardrop in his eye..."
%%%% <[email protected]> % 'One Summer Dream', *Face The Music*, ELO
http://www.digitalsignallabs.com

[bharat pathak]

Randy,

The output wordlength is briefly touched upon in fir.pdf
equations 86 and 87. It just talks about one part of the story,
and that part is overflow, which you have mentioned in your doc.
And maybe this is the reason why you are closely following the
discussion.

I will be sending you a mail shortly with all the details and
equations. Please hold on for sometime, as I am in middle of
some other time critical work.

Regards
Bharat

The World Is Flat: A Brief History of the Twenty-First Century

[faz]

On May 27, 7:10*pm, Randy Yates <[email protected]> wrote:
> faz <[email protected]> writes:
> > On May 27, 5:39*pm, "bharat pathak" <[email protected]> wrote:
> >> >Is there any formula or general rule to set output width of FIR filter
> >> >given its input ,coefficients width and number of taps.??
>
> >> There is no such Formula.
>
> >> >I red in some data sheet of FIR filter deisgn as:
> >> >output width = input width+coefficient width+logN(base 2)
>
> >> >In some other data sheet *of FIR filter deisgn as:
> >> >output width = 2*input width+logN(base 2)
>
> >> Both the formula are incorrect and most probably u would
> >> have read them in some FPGA white paper.
>
> > Hai,
>
> > U cannot say it as incorrect because they are following some practical
> > consideration as given below..
>
> >http://personal.rdu.bellsouth.net/~yatesc/fir.pdf
>
> Hi Faz,
>
> I can't believe that link still works! I haven't had my internet
> service with Bellsouth for at least 3 years! (And that is an
> old version of the paper.)
>
> Please use the following link instead:
>
> *http://www.digitalsignallabs.com/fir.pdf
> *http://www.digitalsignallabs.com/fp.pdf
>
> > Still u are not convinced...then justify why it is wrong??and explain
> > wat is the right way to calculate it??
>
> Faz, Bharat, if I have made an error, please let me know. I will
> be watching this thread.
> --
> % *Randy Yates * * * * * * * * *% "Bird, on the wing,
> %% Fuquay-Varina, NC * * * * * *% * goes floating by
> %%% 919-577-9882 * * * * * * * *% * but there's a teardrop in his eye..."
> %%%% <[email protected]> * * * * * % 'One Summer Dream', *Face The Music*, ELOhttp://www.digitalsignallabs.com

hai,

Your document describe consideration for fixed point number but for
floating point number whether same condition M+N+log2(N) can be used??

regards,
faz

[Randy Yates]

"bharat pathak" <[email protected]> writes:

> Randy,
>
> The output wordlength is briefly touched upon in fir.pdf
> equations 86 and 87. It just talks about one part of the story,
> and that part is overflow, which you have mentioned in your doc.

Well, I mention maintaining precision and avoiding overflow. In other
words, there are at least two "parts of the story" there. Maybe you have
more parts?
--
% Randy Yates % "The dreamer, the unwoken fool -
%% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..."
%%% 919-577-9882 %
%%%% <[email protected]> % 'Eldorado Overture', *Eldorado*, ELO
http://www.digitalsignallabs.com

[Jerry Avins]

Randy Yates wrote:
> "bharat pathak" <[email protected]> writes:
>
>> Randy,
>>
>> The output wordlength is briefly touched upon in fir.pdf
>> equations 86 and 87. It just talks about one part of the story,
>> and that part is overflow, which you have mentioned in your doc.
>
> Well, I mention maintaining precision and avoiding overflow. In other
> words, there are at least two "parts of the story" there. Maybe you have
> more parts?

How about the number of worthwhile (significant) bits? When I measure
the diameter of a tree as 2 inches, it's naive to cite it's
circumference as 6.283185307179586476925286766559 inches. For this kind
of measurement, fractional Angstrom units don't mean much.

When later truncation creates so little noise that the noise from the
original quantization masks it, any more bits are simply wasted.

jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

[Randy Yates]

Jerry Avins <[email protected]> writes:

> Randy Yates wrote:
>> "bharat pathak" <[email protected]> writes:
>>
>>> Randy,
>>>
>>> The output wordlength is briefly touched upon in fir.pdf
>>> equations 86 and 87. It just talks about one part of the story,
>>> and that part is overflow, which you have mentioned in your doc.
>>
>> Well, I mention maintaining precision and avoiding overflow. In other
>> words, there are at least two "parts of the story" there. Maybe you have
>> more parts?
>
> How about the number of worthwhile (significant) bits? When I measure
> the diameter of a tree as 2 inches, it's naive to cite it's
> circumference as 6.283185307179586476925286766559 inches. For this
> kind of measurement, fractional Angstrom units don't mean much.
>
> When later truncation creates so little noise that the noise from the
> original quantization masks it, any more bits are simply wasted.

If you can make some statistical assumptions about the input data, then
perhaps you can get away with fewer bits. But of course in general,
using any fewer bits would lose information.
--
% Randy Yates % "Remember the good old 1980's, when
%% Fuquay-Varina, NC % things were so uncomplicated?"
%%% 919-577-9882 % 'Ticket To The Moon'
%%%% <[email protected]> % *Time*, Electric Light Orchestra
http://www.digitalsignallabs.com

[Jerry Avins]

Randy Yates wrote:
> Jerry Avins <[email protected]> writes:
>
>> Randy Yates wrote:
>>> "bharat pathak" <[email protected]> writes:
>>>
>>>> Randy,
>>>>
>>>> The output wordlength is briefly touched upon in fir.pdf
>>>> equations 86 and 87. It just talks about one part of the story,
>>>> and that part is overflow, which you have mentioned in your doc.
>>> Well, I mention maintaining precision and avoiding overflow. In other
>>> words, there are at least two "parts of the story" there. Maybe you have
>>> more parts?
>> How about the number of worthwhile (significant) bits? When I measure
>> the diameter of a tree as 2 inches, it's naive to cite it's
>> circumference as 6.283185307179586476925286766559 inches. For this
>> kind of measurement, fractional Angstrom units don't mean much.
>>
>> When later truncation creates so little noise that the noise from the
>> original quantization masks it, any more bits are simply wasted.
>
> If you can make some statistical assumptions about the input data, then
> perhaps you can get away with fewer bits. But of course in general,
> using any fewer bits would lose information.

It would lose something, but would what is lost be information?

Would truncating the tree diameter from 6.283185307179586476925286766559
to 6.283, thus reporting it to the nearest thousandth of an inch, (or 25
microns) lose information? What is the meaning of 6.2831853071795864 +/-
..001? It's like giving baking time to milliseconds when the oven
temperature is known only within a few degrees.

DSP is about numbers, and numbers can have any presumed precision. When
those numbers are used to describe something, there is a limit to how
precise the description can meaningfully be.

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

[Randy Yates]

Jerry Avins <[email protected]> writes:

> Randy Yates wrote:
>> Jerry Avins <[email protected]> writes:
>>
>>> Randy Yates wrote:
>>>> "bharat pathak" <[email protected]> writes:
>>>>
>>>>> Randy,
>>>>>
>>>>> The output wordlength is briefly touched upon in fir.pdf
>>>>> equations 86 and 87. It just talks about one part of the story,
>>>>> and that part is overflow, which you have mentioned in your doc.
>>>> Well, I mention maintaining precision and avoiding overflow. In other
>>>> words, there are at least two "parts of the story" there. Maybe you have
>>>> more parts?
>>> How about the number of worthwhile (significant) bits? When I measure
>>> the diameter of a tree as 2 inches, it's naive to cite it's
>>> circumference as 6.283185307179586476925286766559 inches. For this
>>> kind of measurement, fractional Angstrom units don't mean much.
>>>
>>> When later truncation creates so little noise that the noise from the
>>> original quantization masks it, any more bits are simply wasted.
>>
>> If you can make some statistical assumptions about the input data, then
>> perhaps you can get away with fewer bits. But of course in general,
>> using any fewer bits would lose information.
>
> It would lose something, but would what is lost be information?
>
> Would truncating the tree diameter from
> 6.283185307179586476925286766559 to 6.283, thus reporting it to the
> nearest thousandth of an inch, (or 25 microns) lose information? What
> is the meaning of 6.2831853071795864 +/-
> .001? It's like giving baking time to milliseconds when the oven
> temperature is known only within a few degrees.
>
> DSP is about numbers, and numbers can have any presumed
> precision. When those numbers are used to describe something, there is
> a limit to how precise the description can meaningfully be.

I see your point, Jerry. I don't see how you could generalize that
type of property though since it depends very much on the specifics
of the application. But yes, there are certainly times when using
less than L + log_2(alpha) bits is perfectly acceptable. In fact
you MUST do that, e.g., when using the SSE2 architecture since its
"accumulators" are only 32 bits wide (and the input data is 16
bits).
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% <[email protected]> % Getting To The Point', *Balance of Power*, ELO
http://www.digitalsignallabs.com

[bharat pathak]

>Well, I mention maintaining precision and avoiding overflow. In other
>words, there are at least two "parts of the story" there. Maybe you have
>more parts?

Randy,

I agree with you. Stories are only 2, but there is a possibility of
a sub-story to "maintaining precision" and I know of 2 suc
sub-stories.

Sorry for overlooking the "maintaining precision" part in you
document.
Maybe this is an hint to make your document highlight more relevant
information (ofcourse everything is relevant, as it is said beaut
lies
in the eyes of the beholder).

Best Regards
Bharat Pathak

Arithos Designs
www.Arithos.com