[sdiy] Re: IIR and FIR

[Veronica Merryfield]

> Awesome, I've read the second one - this isn't new stuff really, but  
> it seems that as
> I read it over and over and over, I keep picking up more.
That's how I was when I first started messing with them. A good book  
or too really helps although websites are better now than then, well,  
they exist now - back then I was using email to ftp to do GNU  
downloads and discussing state machine CASE with a guy that was  
implementing a new server protocol at CERN.

> I need to get busy and become proficient at using Octave so that I  
> can analyse this
> stuff without having to "build" the filters.
It might help you some but it will probably stop short of helping with  
quantisation issues with lower bit sizes unless you can force bounds  
on the numbers. If you can do this, you could probably run a bounded  
version in parallel with an unbounded version so you can see the  
quantisation error and accumulation on a sample by sample basis.

> Thank you for these URLs.
Google is your friend :) No problem.

> So I'd assume that I need to pay the same kind of attention while  
> using 18 bit signed
> fixed point as well since it's only 2 more bits.
Yes. It is easy to get overflows (usually form the series of MACs) or  
data going to zero when it shouldn't. With big floats, you don't think  
about order of operations, using trig functions and so on but with bit  
limited floats of fixed point numbers, it becomes very important.  
Personally, I think one should be concerned about this sort of thing  
with bigger sized floats because although the float can represent a  
large range of numbers, you still have a fundamental limit on the  
amount of information you can represent based on the number of bits so  
a float is a compromise.

>  Hmm.  I've experimented in C with this while designing filter  
> implementations, I
> usually start with double, but then I will change to 64 bit signed  
> fixed point
> integer arithmetic, and then I chop it down to 18 bit signed integer  
> before writing
> Verilog code.
>
> It seems that it would be useful to have a way to do this  
> "reduction" from float to
> fixed point with Octave - is it possible?  Or should I continue  
> using C for those tests?
I would probably use  C and a fixed input data set for both float and  
fixed however, I have found that spread sheets can be a great asset in  
numerical methods and they can do the graphing in a very convenient  
way - you could output to a CSV file from C and use a spreadsheet to  
graph it.