Randy,
Careful about that extra sign bit. The 54x C compiler assumes it the FRCT
bit on the 54x is 0, i.e. no automatic left shift of one, so if we are
working with "Q15" variable types, then we need to get rid of the extra sign
bit in the final store operation (shift by 15 instead of 16).
result = (INT16_T)(acc >> 15);
I, too, am suprised the C compiler correctly does the MAC, according to the
54x C compilers guide the proper way to guarantee you'll get the correct
result would be to type cast:
for (n = 0; n < VECTOR_LENGTH; n++)
{
acc += ((long) x[n]) *((long) y[n]);
}
I prefer to use the 54x or 55x instrinsics as shown in my first response to
the original question (I have a code example there). Yes this code is NOT
portable (at least to other DSP families), but I'm sure it is doing what I
expect.
-Shawn
"Randy Yates" <randy.yates@sonyericsson.com> wrote in message
news:xxpis47a4nn.fsf@usrts005.corpusers.net...
> Tim Wescott <tim@wescottnospamdesign.com> writes:
>
> > Randy Yates wrote:
> >
> > > Tim Wescott <tim@wescottnospamdesign.com> writes:
> > >
> >
> > >>[...]
> > >>Generally if you stick to pure C you are stuck with integer math.
> > >>DSP's are designed to do fixed-radix math pretty quickly, ...
> > > Tim, I think most of your points are helpful, but this one is
> > > off-the-mark
> >
> > > in my judgement. The typical fixed-point DSP operates much the same as
> > > the C integer operations, performing integer math. Whether the
> > > integers are reinterpreted to be fractional, fixed-point, or integer
> > > is all in the interpretation and has little or nothing to do with the
> > > implementation of the basic arithmetic operations (add, subtract,
> > > multiply).
> > > Of course there are differences between fixed-point DSP ALUs and the
> >
> > > "ALU" of a C compiler, the biggest of which are probably the wide
> > > accumulators and the saturation options when performing various
> > > operations. There is also the typical "left shift by 1" that a
> > > fractional DSP does after a multiply to make the result fractional,
> > > but that is certainly doable in C as well, albeit manually.
> >
> > The difference in clock ticks between implementing a fixed-point
> > arbitrary-radix vector dot-product in assembly on a DSP and trying to
> > do the same thing to the same precision in C on the same processor is
> > on the order of 100:1.
>
> Who said anything about a vector operation? Your statement was
>
> Generally if you stick to pure C you are stuck with integer math.
> DSP's are designed to do fixed-radix math pretty quickly, ...
>
> The term "math" does not mean "vector math" in my interpretation.
>
> > Even on a MAC-less processor when you are in assembly and multiply two
> > signed numbers N-bit numbers you can choose to take the lower N bits
> > of the 2N-1-bit result as C does, or you can take the upper N-1 bits
> > and do a shift, with way fewer clock cycles (10 or 20:1) than you
> > could implement the same functionality in C. I should know -- I've
> > done it in C a couple of times and in assembly on three or four
> > different processors.
>
> Apparently they did not include the TI TMS320C54x, arguably one of
> the most popular DSPs around, and on that processor, the following
> code
>
> #include "dsptypes.h"
>
> /* definitions */
>
> #define VECTOR_LENGTH 64
>
> /* local variables */
>
> /* local function prototypes */
>
> /* function definitions */
>
> int main(int margc, char **margv)
> {
> UINT16_T n;
> INT16_T x[VECTOR_LENGTH];
> INT16_T y[VECTOR_LENGTH];
> INT32_T acc;
> INT16_T result;
>
> acc = 0;
> for (n = 0; n < VECTOR_LENGTH; n++)
> {
> x[n] = n;
> y[n] = VECTOR_LENGTH - n - 1;
> }
>
> acc = 0;
> for (n = 0; n < VECTOR_LENGTH; n++)
> {
> acc += x[n] * y[n];
> }
>
> result = (INT16_T)(acc >> 16);
>
> return result;
> }
>
>
> produces the following assembly language
>
> 0000:0108 main
> 0000:0108 4A11 PSHM 11h
> 0000:0109 4A17 PSHM 17h
> 0000:010A EE80 FRAME -128
> 0000:010B E781 MVMM SP,AR1
> 0000:010C 6DE9 MAR *+AR1(64)
> 0000:010E E787 MVMM SP,AR7
> 0000:010F E782 MVMM SP,AR2
> 0000:0110 E800 LD #0h,A
> 0000:0111 771A STM 3fh,1ah
> 0000:0113 F072 RPTB 11ah
> 0000:0115 L1
> 0000:0115 8092 STL A,*AR2+
> 0000:0116 E93F LD #3fh,B
> 0000:0117 F520 SUB A,0,B
> 0000:0118 8191 STL B,*AR1+
> 0000:0119 F000 ADD #1h,0,A,A
> 0000:011B L2
> 0000:011B E782 MVMM SP,AR2
> 0000:011C 6DEA MAR *+AR2(64)
> 0000:011E E783 MVMM SP,AR3
> 0000:011F E800 LD #0h,A
> 0000:0120 EC3F RPT #3fh
> 0000:0121 L3
> 0000:0121 B089 MAC *AR2+,*AR3+,A,A
> 0000:0122 L4
> 0000:0122 F0E0 SFTL A,0,A
> 0000:0123 F0F0 SFTL A,-16,A
> 0000:0124 6BF8 ADDM 80h,*(18h)
> 0000:0127 F495 NOP
> 0000:0128 F495 NOP
> 0000:0129 8A17 POPM 17h
> 0000:012A 8A11 POPM 11h
> 0000:012B F4E4 FRET
>
> Both the vector multiply and the end shift look pretty damn efficient
> to me, Tim.
>
> Thus even if we agree to interpret your point differently, it's still
> inaccurate for one of the most popular DSPs in the world.
> --
> Randy Yates
> Sony Ericsson Mobile Communications
> Research Triangle Park, NC, USA
> randy.yates@sonyericsson.com, 919-472-1124
Porting LMS from floating-point to fixed-point processor
Started by ●March 3, 2005
Reply by ●March 4, 20052005-03-04
Reply by ●March 5, 20052005-03-05
"Shawn Steenhagen" <shawn.NSsteenhagen@NSappliedsignalprocessing.com> writes:> Randy, > > Careful about that extra sign bit.Shawn, your warning is ludicrous. My paper on scaling in FIR fixed-point arithmetic - a reference for many who have visited this group looking for information on the topic - discusses this point. I wrote it years before I ever heard of your name on this group. I am also the author of the comp.dsp FAQ item on fixed-point arithmetic and as such am well-versed on the issue. I noticed your tendency to assume I was ignorant at the comp.dsp conference. Perhaps you should reexamine your assumptions to save yourself further embarassment. I'm not going to honor your point with a response except to say that you have given me no new information and I still stand by everything I have asserted in this thread. -- % Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. %% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and %%% 919-577-9882 % Verdi's always creepin' from her room." %%%% <yates@ieee.org> % "Rockaria", *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●March 5, 20052005-03-05
Jerry Avins <jya@ieee.org> writes:> Randy Yates wrote: >> Jerry Avins <jya@ieee.org> writes: > > ... > >>>There is -- or can be -- a slight but significant difference with >>>multiplication. Coding the shift in C can use a few extra cycles. >> Yes, in the case where you are doing the left shift, there may be >> extra cycles required to do this in C. However, this isn't always the >> case, and when it is the case, the number of cycles in the difference >> will probably be between 0 and "not very many," depending on the >> compiler, the specific types of operations being performed, and the >> ingenuity of the programmer. >> Thus the distinction does not warrant a generic caveat regarding >> fixed-point arithmetic in C, in my opinion. > > What general caveat, "Watch out for gotchas"?No. The original caveat asserted by Tim Wescott, which you seem to be defending, albeit in an askance manner.>>>Since the choice between fixed-point and integer multiplication is >>> made with a bit in a register, >> It is this sort of thinking that is propagating the error in this >> thread. This logic is tantamount to saying that "the difference >> between a Ford and a Chevy is that a Ford has a better ride." It >> attempts to generalize what may be true in a specific case. > > I don't understand. Can I expect a C compiler to change the > integer/~fixed bit as appropriate?No, you cannot. HOWEVER... "Fixed-point" does NOT *generally* mean you are going to left shift after a multiply!!!>>>I doubt that any compiler that knows >>> only integer would do fixed point efficiently. >> Did you see my other post where I gave actual code that refutes this? > > Yes. Impressive but, I suspect, rare.You're free to embrace your suspicions, but in my opinion you're bordering on being obstinately ignorant. This is my job, Jerry. I do this EXACT type of activity many times during the course of my development work at Sony Ericsson, and I'm telling you that fixed-point arithmetic in C is VERY doable. There are some caveats and limitations, but for the most part I've been able to use C to simulate my fixed-point code. My typical flow when developing an algorithm routine is as follows: 1) exploration and experimentation in Matlab until a candidate algorithm is found, 2) translate to fixed-point by writing a C simulation on the Sun, 3) either retarget the Sun C code to the DSP (if speed isn't crucial) or reimplement in assembly on the DSP. Do you think that I specially-formulated the posted code so that it would compile efficiently? I did not. In fact the code you have in that post is the very first thing I tried. Tim Wescott had asserted that vector multiplication was inefficient in C on a DSP. Now I'm not sure what sort of strange variations on vector multiplies you want to present as exceptions, but it seems to me that the operation is pretty clearly defined.>>>There are other >>>differences that just occurred to me. In the fixed-point shift, what >>>had been the MSB of the low-order word becomes the LSB of the returned >>> result; >> I'm not sure of the scenario you're trying to describe here. > > The product of a 32-by-32 multiply has 64 bits. Numbering them zero to > 63 in increasing significance, an ordinary integer multiply returns > zero to 31, or zero to 30 plus the sign bit, 63. A fixed-point > multiply should return bits 31 to 62 of the product. Shifting the > upper word alone forces bit 31 to zero. (I think I could be > clearer. Should I try?)I see. Who said that shifts occur in 16-bit chunks? In C, you would presumably maintain a 32-bit variable to hold the result, and when you shift it, you shift the entire 32 bits. In assembly, the accumulator is holding the result, and when you shift it, you shift the entire accumulator. Thus this appears to be a non-problem.>>>that's not possible with a HLL integer multiply. Worse, an HLL >>>integer multiply returns the low word of the product. A fixed-point >>> multiply returns (mostly) the high word. >> Not necessarily. Depends on what you're doing. > > Please elaborate.Read my paper on fixed-point considerations in FIR filtering and you'll understand. The 16-bits you extract from a 40-bit accumulator (to stick with a TI-ish architecture) can be all over the map depending your objective, the algorithm, the input scaling, and the output scaling. This will also help to cement why "fractional" is a small part of the "fixed-point" world.>>>I can remedy this with int in >>>C by promoting to long, then multiplying, shifting, and truncating to >>>int. That's painful (although it could be a macro) and time >>> consuming. >> What's so time-consuming about it? It might cost you one cycle. Big >> whoop. > > Better than I supposed by far. I may give up on assembler after all!Unless you need to shave the last few ten percent off your execution time, I'd say C is fine for fixed-point. In my line of work, it is often the case that you do want to save that last few ten percent, especially since such operations are usually in the most expensive "inner-loop" portion of the algorithm.>>>And it won't work with longs. >> True unless the compiler supports an extended long, i.e., an integer >> the size of the accumulator. Although double-precision multiplication >> takes us pretty far afield from the topic. >>>That's too stupid a scenario. What am I missing? >> I think you're right - you are just beginning to think about more of >> the details. > > I hate psyching out a compiler when I know what I want in the > end. "Just do it" never seemed more appropriate.Well, there is an advantage in doing a small amount of finagling in 2 percent of the code when coding the other 98 percent assembly would be painful. -- % Randy Yates % "Maybe one day I'll feel her cold embrace, %% Fuquay-Varina, NC % and kiss her interface, %%% 919-577-9882 % til then, I'll leave her alone." %%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO http://home.earthlink.net/~yatescr
Reply by ●March 5, 20052005-03-05
Randy Yates <yates@ieee.org> writes:>> The product of a 32-by-32 multiply has 64 bits. Numbering them zero to >> 63 in increasing significance, an ordinary integer multiply returns >> zero to 31, or zero to 30 plus the sign bit, 63. A fixed-point >> multiply should return bits 31 to 62 of the product. Shifting the >> upper word alone forces bit 31 to zero. (I think I could be >> clearer. Should I try?) > > I see. Who said that shifts occur in 16-bit chunks? In C, you would > presumably maintain a 32-bit variable to hold the result, and when you > shift it, you shift the entire 32 bits. In assembly, the accumulator > is holding the result, and when you shift it, you shift the entire > accumulator. Thus this appears to be a non-problem.Sorry - I had lost context when writing that. Translate "32" and "16" to "64" and "32". The conclusion is still the same. This is a non-problem. -- % Randy Yates % "Midnight, on the water... %% Fuquay-Varina, NC % I saw... the ocean's daughter." %%% 919-577-9882 % 'Can't Get It Out Of My Head' %%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by ●March 5, 20052005-03-05
Randy Yates wrote:> Jerry Avins <jya@ieee.org> writes: > > >>Randy Yates wrote: >> >>>Jerry Avins <jya@ieee.org> writes: >> >> ... >> >> >>>>There is -- or can be -- a slight but significant difference with >>>>multiplication. Coding the shift in C can use a few extra cycles. >>> >>>Yes, in the case where you are doing the left shift, there may be >>>extra cycles required to do this in C. However, this isn't always the >>>case, and when it is the case, the number of cycles in the difference >>>will probably be between 0 and "not very many," depending on the >>>compiler, the specific types of operations being performed, and the >>>ingenuity of the programmer. >>>Thus the distinction does not warrant a generic caveat regarding >>>fixed-point arithmetic in C, in my opinion. >> >>What general caveat, "Watch out for gotchas"? > > > No. The original caveat asserted by Tim Wescott, which you seem to be > defending, albeit in an askance manner. > > >>>>Since the choice between fixed-point and integer multiplication is >>>>made with a bit in a register, >>> >>>It is this sort of thinking that is propagating the error in this >>>thread. This logic is tantamount to saying that "the difference >>>between a Ford and a Chevy is that a Ford has a better ride." It >>>attempts to generalize what may be true in a specific case. >> >>I don't understand. Can I expect a C compiler to change the >>integer/~fixed bit as appropriate? > > > No, you cannot. HOWEVER... "Fixed-point" does NOT *generally* mean you > are going to left shift after a multiply!!!OK. Then what error's propagation were you referring to?>>>>I doubt that any compiler that knows >>>>only integer would do fixed point efficiently. >>> >>>Did you see my other post where I gave actual code that refutes this? >> >>Yes. Impressive but, I suspect, rare. > > > You're free to embrace your suspicions, but in my opinion you're > bordering on being obstinately ignorant. This is my job, Jerry. I do > this EXACT type of activity many times during the course of my > development work at Sony Ericsson, and I'm telling you that > fixed-point arithmetic in C is VERY doable. There are some caveats and > limitations, but for the most part I've been able to use C to simulate > my fixed-point code.By rare, I mean a few compilers tailored specifically to DSP by DSP a manufacturer. That's what I suspect. If you tell me otherwise, I'll happily accept it. I believe very strongly that you know what you're talking about. I think that very often, we don't know what the other is talking about.> My typical flow when developing an algorithm routine is as follows: > 1) exploration and experimentation in Matlab until a candidate > algorithm is found, 2) translate to fixed-point by writing > a C simulation on the Sun, 3) either retarget the Sun C code > to the DSP (if speed isn't crucial) or reimplement in assembly > on the DSP. > > Do you think that I specially-formulated the posted code so that it > would compile efficiently? I did not. In fact the code you have in > that post is the very first thing I tried. Tim Wescott had asserted > that vector multiplication was inefficient in C on a DSP. Now I'm not > sure what sort of strange variations on vector multiplies you want to > present as exceptions, but it seems to me that the operation is pretty > clearly defined.You just told me otherwise. Good! (I never mentioned vector multiplies. To my discredit, I don't even think that way.)>>>>There are other >>>>differences that just occurred to me. In the fixed-point shift, what >>>>had been the MSB of the low-order word becomes the LSB of the returned >>>>result; >>> >>>I'm not sure of the scenario you're trying to describe here. >> >>The product of a 32-by-32 multiply has 64 bits. Numbering them zero to >>63 in increasing significance, an ordinary integer multiply returns >>zero to 31, or zero to 30 plus the sign bit, 63. A fixed-point >>multiply should return bits 31 to 62 of the product. Shifting the >>upper word alone forces bit 31 to zero. (I think I could be >>clearer. Should I try?) > > > I see. Who said that shifts occur in 16-bit chunks? In C, you would > presumably maintain a 32-bit variable to hold the result, and when you > shift it, you shift the entire 32 bits. In assembly, the accumulator > is holding the result, and when you shift it, you shift the entire > accumulator. Thus this appears to be a non-problem.With a 32-by-32 fixed-point fractional multiply, I first get a 64-bit result, then shift left one bit and keep the resulting high 32 bits. Where do the 16-bit chunks fit in?>>>>that's not possible with a HLL integer multiply. Worse, an HLL >>>>integer multiply returns the low word of the product. A fixed-point >>>>multiply returns (mostly) the high word. >>> >>>Not necessarily. Depends on what you're doing. >> >>Please elaborate. > > > Read my paper on fixed-point considerations in FIR filtering and > you'll understand. The 16-bits you extract from a 40-bit accumulator > (to stick with a TI-ish architecture) can be all over the map > depending your objective, the algorithm, the input scaling, and the > output scaling. This will also help to cement why "fractional" is a > small part of the "fixed-point" world.The only hardware fixed-point support I'm aware is pure fractional, hence the orientation of mt statements. Also I had in mind the 'C31's 32-bit word size. I've been using scaled integers with all sorts of scaling factors for many years, both in Forth and in assembly, mostly on 8-bit processors with multiple-precision arithmetic. (Before IEEE standardization of floats, it was the best way I knew to write bit-reproducible code.)>>>>I can remedy this with int in >>>>C by promoting to long, then multiplying, shifting, and truncating to >>>>int. That's painful (although it could be a macro) and time >>>>consuming. >>> >>>What's so time-consuming about it? It might cost you one cycle. Big >>>whoop. >> >>Better than I supposed by far. I may give up on assembler after all! > > > Unless you need to shave the last few ten percent off your execution time, > I'd say C is fine for fixed-point. In my line of work, it is often the > case that you do want to save that last few ten percent, especially since > such operations are usually in the most expensive "inner-loop" portion > of the algorithm.You've convinced me that it is, but you haven't convinced me that by just using integer, everything will work out. I believe something you wrote in the post that elicited my first response implied that. Here: "The typical fixed-point DSP operates much the same as the C integer operations, performing integer math. Whether the integers are reinterpreted to be fractional, fixed-point, or integer is all in the interpretation and has little or nothing to do with the implementation of the basic arithmetic operations ..." Surely, there's always some adjustment needed after multiplying, however little time it may take. ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●March 5, 20052005-03-05
Randy Yates wrote: - snip -> > Do you think that I specially-formulated the posted code so that it > would compile efficiently? I did not. In fact the code you have in > that post is the very first thing I tried. Tim Wescott had asserted > that vector multiplication was inefficient in C on a DSP. Now I'm not > sure what sort of strange variations on vector multiplies you want to > present as exceptions, but it seems to me that the operation is pretty > clearly defined. >I think that for the most part we're in violent agreement - but you seem to have (a) have worked mostly with DSP chips with very good tool support, and (b) to have missed out on the learning curve that many software folks have when doing DSP for the first time. Your speed ratios are contrary to my experience with CISC and RISC processors, and with older DSP toolsets. I see much closer to 1:1 ratios with the '2812, but even there you can slow things down if you're not careful, and the optimizer will sometimes take your code and fling it on the trash pile without telling you (which, I assume, is why they call it Code Composter). I even tried to get Code Composter for the TMS320F2812 to cough up a MAC instruction -- it wouldn't do it for love or money. I'm tempted to try your code snippet on one the next time I'm at that particular customer site, just to see what happens. I'm curious though -- since you cite that code snippet why haven't you commented on the non-ANSI translation done by the '5xxx "C" compiler? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 8, 20052005-03-08
d.lohausen@freenet.de (Daniel) wrote in message news:<e83ccc31.0503030745.68a487cc@posting.google.com>...> Hello Everybody, > > for my diploma thesis, I have to implement a Least-Mean-Square > Algorithm on a fixed-point DSP (TI 6416). The LMS was implemented on a > floating-point processor(TI 6713) earlier, so I just to the code and > copied it. Of course, there are a lot of float variables in the code. > When I ran the program, it workes for small FIR orders (6), but the > larger the order of the filter, the worse the result. > Is this because the 6416 cannot work with floating-point numbers > accuretly? > What can I do? When I convert all the float variables to integers I > get overflow problems. > > Thanks a lot > DanielHello Everybody, thanks for all you help. I found out that the algorithm was too slow in my application. For higher filter orders, the LMS was still calculating when new samples from the codec had arrived. A software interrupt was called that started the LMS from the beginning, so it didn`t end the previous cycle. Now I removed all the codec stuff and I works for higher filter orders, but, of course, far too slow. Now I have to adapt the algorithm to fixed-point. I read all the posts and I have a new question: I understand what the Q.15 data type is but how can I use in in C? Is there a special data type or what? Thanks again Daniel
Reply by ●March 8, 20052005-03-08
Daniel wrote:> d.lohausen@freenet.de (Daniel) wrote in messagenews:<e83ccc31.0503030745.68a487cc@posting.google.com>...> > Hello Everybody, > > > > for my diploma thesis, I have to implement a Least-Mean-Square > > Algorithm on a fixed-point DSP (TI 6416). The LMS was implementedon a> > floating-point processor(TI 6713) earlier, so I just to the codeand> > copied it. Of course, there are a lot of float variables in thecode.> > When I ran the program, it workes for small FIR orders (6), but the > > larger the order of the filter, the worse the result. > > Is this because the 6416 cannot work with floating-point numbers > > accuretly? > > What can I do? When I convert all the float variables to integers I > > get overflow problems. > > > > Thanks a lot > > Daniel > > Hello Everybody, > > thanks for all you help. I found out that the algorithm was too slow > in my application. For higher filter orders, the LMS was still > calculating when new samples from the codec had arrived. A software > interrupt was called that started the LMS from the beginning, so it > didn`t end the previous cycle. > Now I removed all the codec stuff and I works for higher filter > orders, but, of course, far too slow. Now I have to adapt the > algorithm to fixed-point. > > I read all the posts and I have a new question: I understand what the > Q.15 data type is but how can I use in in C? Is there a special data > type or what? > > Thanks again > DanielI think this has been discussed in this thread already. John
Reply by ●March 8, 20052005-03-08
Daniel wrote:> d.lohausen@freenet.de (Daniel) wrote in messagenews:<e83ccc31.0503030745.68a487cc@posting.google.com>...> > Hello Everybody, > > > > for my diploma thesis, I have to implement a Least-Mean-Square > > Algorithm on a fixed-point DSP (TI 6416). The LMS was implementedon a> > floating-point processor(TI 6713) earlier, so I just to the codeand> > copied it. Of course, there are a lot of float variables in thecode.> > When I ran the program, it workes for small FIR orders (6), but the > > larger the order of the filter, the worse the result. > > Is this because the 6416 cannot work with floating-point numbers > > accuretly? > > What can I do? When I convert all the float variables to integers I > > get overflow problems. > > > > Thanks a lot > > Daniel > > Hello Everybody, > > thanks for all you help. I found out that the algorithm was too slow > in my application. For higher filter orders, the LMS was still > calculating when new samples from the codec had arrived. A software > interrupt was called that started the LMS from the beginning, so it > didn`t end the previous cycle. > Now I removed all the codec stuff and I works for higher filter > orders, but, of course, far too slow. Now I have to adapt the > algorithm to fixed-point. > > I read all the posts and I have a new question: I understand what the > Q.15 data type is but how can I use in in C? Is there a special data > type or what? > > Thanks again > DanielMakes sense. Just use integer type and play around with a few multiples and look at the results, everything will make sense if you try a small algorithm.
Reply by ●March 8, 20052005-03-08
d.lohausen@freenet.de (Daniel) writes:> d.lohausen@freenet.de (Daniel) wrote in message news:<e83ccc31.0503030745.68a487cc@posting.google.com>... > > Hello Everybody, > > > > for my diploma thesis, I have to implement a Least-Mean-Square > > Algorithm on a fixed-point DSP (TI 6416). The LMS was implemented on a > > floating-point processor(TI 6713) earlier, so I just to the code and > > copied it. Of course, there are a lot of float variables in the code. > > When I ran the program, it workes for small FIR orders (6), but the > > larger the order of the filter, the worse the result. > > Is this because the 6416 cannot work with floating-point numbers > > accuretly? > > What can I do? When I convert all the float variables to integers I > > get overflow problems. > > > > Thanks a lot > > Daniel > > Hello Everybody, > > thanks for all you help. I found out that the algorithm was too slow > in my application. For higher filter orders, the LMS was still > calculating when new samples from the codec had arrived. A software > interrupt was called that started the LMS from the beginning, so it > didn`t end the previous cycle. > Now I removed all the codec stuff and I works for higher filter > orders, but, of course, far too slow. Now I have to adapt the > algorithm to fixed-point. > > I read all the posts and I have a new question: I understand what the > Q.15 data type is but how can I use in in C? Is there a special data > type or what?No. Simply use a 16-bit integer on your platform and then follow the rules for fixed-point arithmetic, which I give in my paper: http://home.earthlink.net/~yatescr/fp.pdf You should also be careful, as Tim Wescott has correctly pointed out, to ensure intermediate results are properly computed by the C compiler. E.g., to ensure the two 16-bit values are multiplied using a 32-bit result, do the following explicit cast: INT32_T y; /* this is scaled A(1, 30) INT16_T x1; /* this is scaled A(0, 15) INT16_T x2; /* this is scaled A(0, 15) y = (INT32_T)x1 * x2. Similarly if you want to add two A(0, 15) values, you still will want to explicitly cast one operand to 32 bits if you want to ensure you avoid overflows. You're going to have to become an expert on C type conversions to be sure things work the way you expect. -- Randy Yates Sony Ericsson Mobile Communications Research Triangle Park, NC, USA randy.yates@sonyericsson.com, 919-472-1124
