# Fixed-point Math help - Page 3

#### Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

•  Subject
• Author
• Posted on
Re: Fixed-point Math help

For light DSP on conventional processors I usually end up writing a
little fixed-point math package that (a) allows multiplication as
fractional numbers and (b) automatically saturates additions and
subtractions.  This is usually a much better fit for implementing
filters and the like, yet is much faster than floating point on most
machines (including the Pentium, oddly enough).

It's easy enough to simulate the effects of the fixed-point math in
Simulink or whatnot by the judicious use of quantification.  If you get
ambitious enough you can even build a filter library in C or C++, with a
matching library of blocks in your simulation program.

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed-point Math help

When the filter parameters are constant the fastest method is hardcoding
the math in assembly as sequences of shifts and adds.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed-point Math help

True, and if I were working on products at high enough volumes, or small
enough processors to justify it that's just what I'd do.  In fact that's
how my first few experiences with doing DSP in conventional processors went.

Aside from those early experiences I've always worked on things that
ship a few hundred units a year at best, and in the context of a large
SW engineering team of whom I'm the most accomplished at DSP.  Given
processor and code in a high-level language -- that keeps the
engineering time down and gives me the hope that I can do other things
with my time than write numeric processing code.

On a DSP the way I've done it is to write a fast vector dot product and
a fast matrix multiply in assembly, then wrap that with C or C++ to
generate the gain vectors (or matrices).  I get nearly all the
ease-of-use of the higher level language and nearly all the speed of
assembly, which is pretty nice.

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Fixed-point Math help

There's nothing wrong in capitalizing on your prior efforts.  If you've already
tested your algorithms extensively using floating point *and* if you will be
using a floating point package that EXACTLY duplicates the behavior you tested
on the PC then you are in luck and it makes sense.  But your comment seems just
a little cavalier to me, so I'll expand on my point.

What many people do NOT realize is that floating point operation behavior
introduces unexpected (to some) issues, such as the fact that A*(B-C) is not the
same as A*B-A*C in floating point while it IS the same in integer domains.
Floating point is ALSO not the same in behavior from one implementation to
another, many implementations introducing unexpected behaviors in the lower
order bits that differ widely; including non-monotonicities in various functions
of various sizes, different support for features, and hidden rounding controls
that either aren't well documented and/or aren't even properly initialized at
startup and will have to be tracked down in the target.

Just supporting an "identical floating point format" is often enough NOT CLOSE
to supporting identical behaviors in operating on those formats.  And though it
may look good at first blush, you may discover problems well after you've
started to ship product.  And then it can become very expensive to remedy.

I spend a LOT of time carefully studying any floating point software package
before I dare to rely on it and I use what I learn about its behavior in my
design analysis for the algorithms.  This extra work is one reason I often avoid
floating point entirely.  It's hard to do and it takes time to verify the impact
upon equations and to assure one's self through theory that the bounds of the
errors are in the worst case entirely acceptable.

I can't say this about anyone here in particular, but it has been the result of
my long experience in this that programmers I've been exposed to simply do not
have the training (self- or otherwise) to do the analysis carefully, are almost
completely ignorant of the pitfalls in using floating point and are blindly
cavalier and overconfident about its safety, and that they instead depend on
"random" testing of the entire system to assure themselves that things are okay.

Of course, sometimes it is a trivial result that the use of the floating point
is entirely safe -- for example, say, in converting an integer fixed point
internal Fahrenheit value into a rounded/truncated Celsius value for display
(there are all-integer ways, but FP is ... convenient and readable.)  But quite
often equations are developed and handed over to programmers by physicists or
engineers who are NOT cognizant of FP "gotchas" and implemented by programmers
who are also NOT cognizant of them and things "slip through the cracks" between
those wielding equations in a perfect mathematical world and those converting
them to coded sequential operations in an embedded processor.

So I tend to be one of those suggesting that unless you are competent at FP that
you stay away from it.  And if your application requires a wide dynamic range
and you need to maintain a similar precision throughout, then by all means use
floating point but think carefully about its use.  I consider getting the
algorithms working well on a PC a reasonably good idea to ferret out and
eliminate certain kinds of important errors.  But I also do NOT think, assuming
that the same format (and having the same number of bits does NOT mean the 'same
format') is used, that it is then a necessary consequence that all is right with
the world.  There are just too many vagaries to contend with and in the floating
point domain, they can rise up and bite you where you least expect it if you
haven't been bothered to think through them to eliminate their threats.

(1) if your application isn't floating-point heavy and most of it is in dealing
with the external world, timing, stuff like that... then perhaps the risks of
being ignorant are lower.  But still, (a) it probably isn't really that much
work to just avoid the floating point altogether and (b) your foot print in
memory will benefit from not linking FP code, too, and (c) any testing you did
on the PC for those floating point operations should really be just duplicated
on the target where you *know* it applies (and it won't be so difficult to do,
since they are a small part of the overall application);

(2) if your application is floating-point heavy, then the risks of some
difference in handling is just that much more likely to accumulate into a
serious problem.  For all that testing you did on the PC, which was decidedly
convenient and important to do, it still cannot be assumed to operate exactly
the same on your target (unless the target is a Pentium, I suppose.)  And you'll
need to either carefully think through the differences or else duplicate the
work, perhaps.

Floating point is one of those very convenient Ginsu knives that you see doing
such wonderful things in the hands of a skilled practitioner.  But in the hands
of someone who is unskilled and cavalier and ignorant of its dangers, while it
will often do what is expected and thus feed overconfidence in its use, it's
also much more likely to cut off one's finger as chop carrots.

Of course, time to market, etc., will impact choices and risks taken.  Your
mileage may vary, etc.  Just a word to the wise, is all.

Jon

re:Fixed-point Math help
For those of you wondering how the C28x (F2812) from TI handle
floating point so efficiently you can view a .ppt training on th

http://ti-training.com/courses/CourseDescription.asp?iCSID46%234&DCMP=dsp_c2000_iqmath&HQS=On-LineTraining+BA+iqmatholtrellin

There are benchmarks and application examples

Here is the free IQMath Library Itsel
http://focus.ti.com/docs/toolsw/folders/print/sprc087.htm

Chris Clearma

Texas Instrument
C2000 Digital Signal Controller

Re: re:Fixed-point Math help