From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Brian Drummond <brian@shapes.demon.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: RFC:  Generic Fixed-Point IIR Filter
Date: Fri, 27 Mar 2015 11:37:13 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <mf3fd9$udn$1@dont-email.me>
References: <a05f90b1-491d-4e9a-8a01-722c6a136668@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 27 Mar 2015 11:37:13 +0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="da745e888d4a5182b5fda6212bbb0a63";
	logging-data="31159"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18sK7LLjRi91zChfO7wHhoX7890RcU5YGQ="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508
 git://git.gnome.org/pan2)
Cancel-Lock: sha1:i2A6+NmDaSZeIs6CiVga3WJbVVw=
Xref: news.eternal-september.org comp.lang.ada:25286
Date: 2015-03-27T11:37:13+00:00
List-Id: <comp.lang.ada>

On Thu, 26 Mar 2015 09:25:25 -0700, Patrick Noffke wrote:

> I would greatly appreciate some feedback/help on implementing a generic
> fixed-point IIR filter package.
...
> 
>  - If I try to use Fixed_Type for X_Array and Y_Array, then I do in fact
>  get a constraint error (due to range overflow for an intermediate
>  calculation).  Is there a better way to do a calculation for a
>  fixed-point type when you expect the result to be within the specified
>  range of Fixed_Type, but intermediate calculations may not?

I wrote (adapted) a generic SVD (matrix operation) to instantiate with 
either fixed or floating point. The original was floating point : the 
intent was to investigate if different fixed point formats could be made 
stable, before porting to VHDL and implementing in hardware. It quickly 
answered the question : for matrix inversion, no way!

Intermediate addition operations seemed OK : intermediate operations 
involving multiplication (or division) had to be rewritten using 
intermediate variables. 

A moment's thought showed this made sense : you may want the intermediate 
results stored at a different resolution : this is also usually the case 
with IIR filters.

In other words I had to break up 
   f := a * b * c;
into something like
   temp := b * c; 
   f := a * temp;
where temp may have been a higher resolution type, which allowed (i.e. 
forced!) me to explicitly control the numerical properties. This is the 
point Randy made, 4.5.5(19.1/2).

>  - is there another way to
>  define the constants that will "convert" them to a multiple of small?

I would probably use a conversion function on real (float) constants.

>  - I realize my range and precision for Filter_Value_Type are not
>  necessarily ideal (the range depends on the filter coefficients, the
>  filter architecture, as well as the filter order).  Do you know of any
>  references or have suggestions for how to analyze a filter to determine
>  the ideal range and precision?

Signal processing texts aimed at hardware engineers should cover this : 
"Synthesis and optimisation of DSP Algorithms" (Constantinides,Cheung,Luk) 
comes to mind. But with a generic, you can instantiate it with different 
fixed (and float) types, measure the quality of each, and choose.

-- Brian