"Andor" <an2or@mailcircuit.com> wrote in news:1117724924.118207.181750 @g14g2000cwa.googlegroups.com:> Al wrote: > >>OK, I'll bite, which floating point form? > > I'm not allowed to say which floating-point IIR architecture we (where > I work) find gives the best results. Much has been written on this > topic, though, and a thorough literature search should result in some > pointers. > >>The problem with the floating point forms is that subtraction and >>addition kills you. For example, a big float - another big float = >>imprecise little float. This can be minimised to some extent by using a >>higher precision float such as the 40 bit version in the SHARC (32 bit >>mantissa & sign + 8 bit exponent) > > I've been thinking about the following little game: You and I each > write a program for the SHARC DSP that computes some specifiable number > of IIR biquads. You use the best available fixed-point implementation, > using the 32bit / 80bit fixed-point MAC unit. I use our floating-point > implementation using the 32bit / 40bit floating-point MAC unit. Each of > us must use 32bit precision intermediate variables for the filter > states (note that this gives an inherent drawback for floating-point, > because 40bit floating-point filter states could be used with no > additional cost of the CPU time, and thus the floating-point > performance could be improved for free - but let's compare apples to > apples). > > Now, each party gets to choose an arbitrary input signal (we can define > the input format to be 24bit fixed-point), and an arbitrary set of > biquad specifications. You choose an input signal and some biquad > filter specifications where you think the fixed-point implementation > shines and the floating-point implementation fails miserably, and we > each run that signal through our filter routines and compare the > outputs. Likewise, I get to choose a set of biquads and a test signal, > and again we compare the outputs of our routines. > > We then measure the SNR induced by our respective routines (since we > know what the theoretical output should be) and compare the results. > I'm pretty sure I can ruin any fixed-point implemenation with the > appropriate filter specificiations (using two or perhaps three biquads > in series) and input signal, such that the floating-point > implementation will perform reasonably well with the same test case > (although I haven't tried this out yet). Do you think you could do the > same to show the converse :-) ? > >>Mark Allie gave a good presentation on this topic at last year'scomp.dsp>>conference. > > Yes, I just read his talk on your CD (that was probably the best spend > $25 in my working life!). His discussion of error feedback on DF1 and > DF2 biquad architectures is very interesting. > > Regards, > Andor >I'm not sure I want to compare "black boxes" of IIR filters. I don't think the various direct forms in floating point will do as well as a DF I implemented in fixed point where a long accumulator is available (like every fixed point DSP chip). I have googled this topic extensively already. There are also a number of good AES papers on this topic, mostly written when Motorola 56K was still the most popular DSP family in audio. I do think it would be interesting to compare actual filters. Danville has web space available for anyone who wants to contribute an application note comparing IIR filter topologies implemented on the SHARC. The error feedback trick is almost free with the DF I. There may be some alternative Lattice based structures that work well. I haven't studied these very much. I think that we can agree that one of the nice things about the SHARC is that you can use whatever format you prefer. I like fixed point for IIRs & FIRs, floating point for FFTs and RMS detectors. Originally, I was going to create my own version of "Mark's talk". I managed to talk Mark into doing it instead and he did a great job. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
IIR with fixed-point numbers?
Started by ●May 24, 2005
Reply by ●June 2, 20052005-06-02
Reply by ●June 2, 20052005-06-02
"Al Clark" <dsp@danvillesignal.com> wrote in message news:Xns9669B2ED99C3Aaclarkdanvillesignal@66.133.129.71...> "Andor" <an2or@mailcircuit.com> wrote in news:1117724924.118207.181750 > @g14g2000cwa.googlegroups.com: > > > Al wrote: > > > >>OK, I'll bite, which floating point form? > > > > I'm not allowed to say which floating-point IIR architecture we (where > > I work) find gives the best results. Much has been written on this > > topic, though, and a thorough literature search should result in some > > pointers. > > > >>The problem with the floating point forms is that subtraction and > >>addition kills you. For example, a big float - another big float = > >>imprecise little float. This can be minimised to some extent by using a > >>higher precision float such as the 40 bit version in the SHARC (32 bit > >>mantissa & sign + 8 bit exponent) > > > > I've been thinking about the following little game: You and I each > > write a program for the SHARC DSP that computes some specifiable number > > of IIR biquads. You use the best available fixed-point implementation, > > using the 32bit / 80bit fixed-point MAC unit. I use our floating-point > > implementation using the 32bit / 40bit floating-point MAC unit. Each of > > us must use 32bit precision intermediate variables for the filter > > states (note that this gives an inherent drawback for floating-point, > > because 40bit floating-point filter states could be used with no > > additional cost of the CPU time, and thus the floating-point > > performance could be improved for free - but let's compare apples to > > apples). > > > > Now, each party gets to choose an arbitrary input signal (we can define > > the input format to be 24bit fixed-point), and an arbitrary set of > > biquad specifications. You choose an input signal and some biquad > > filter specifications where you think the fixed-point implementation > > shines and the floating-point implementation fails miserably, and we > > each run that signal through our filter routines and compare the > > outputs. Likewise, I get to choose a set of biquads and a test signal, > > and again we compare the outputs of our routines. > > > > We then measure the SNR induced by our respective routines (since we > > know what the theoretical output should be) and compare the results. > > I'm pretty sure I can ruin any fixed-point implemenation with the > > appropriate filter specificiations (using two or perhaps three biquads > > in series) and input signal, such that the floating-point > > implementation will perform reasonably well with the same test case > > (although I haven't tried this out yet). Do you think you could do the > > same to show the converse :-) ? > > > >>Mark Allie gave a good presentation on this topic at last year's > comp.dsp > >>conference. > > > > Yes, I just read his talk on your CD (that was probably the best spend > > $25 in my working life!). His discussion of error feedback on DF1 and > > DF2 biquad architectures is very interesting. > > > > Regards, > > Andor > > > > I'm not sure I want to compare "black boxes" of IIR filters. I don't > think the various direct forms in floating point will do as well as a DF > I implemented in fixed point where a long accumulator is available (like > every fixed point DSP chip). I have googled this topic extensively > already. There are also a number of good AES papers on this topic, mostly > written when Motorola 56K was still the most popular DSP family in audio. > > I do think it would be interesting to compare actual filters. Danville > has web space available for anyone who wants to contribute an application > note comparing IIR filter topologies implemented on the SHARC. > > The error feedback trick is almost free with the DF I. > > There may be some alternative Lattice based structures that work well. I > haven't studied these very much. > > I think that we can agree that one of the nice things about the SHARC is > that you can use whatever format you prefer. I like fixed point for IIRs > & FIRs, floating point for FFTs and RMS detectors. > > Originally, I was going to create my own version of "Mark's talk". I > managed to talk Mark into doing it instead and he did a great job.For me, quality and execution time are both important. I want to use the cheapest filter type that gives me "acceptable" quality. So even if there is some fancy filter topology available to make floating-point as good as or better than fixed point, if it takes significantly longer to execute than simple direct forms in fixed-point, that's not an ideal solution. So a "black box" comparison of filters would need to be augmented with benchmarks to be useful for me.
Reply by ●June 2, 20052005-06-02
"Jon Harris" <jon_harrisTIGER@hotmail.com> wrote in news:119v61l911amb82@corp.supernews.com:> "Al Clark" <dsp@danvillesignal.com> wrote in message > news:Xns9669B2ED99C3Aaclarkdanvillesignal@66.133.129.71... >> "Andor" <an2or@mailcircuit.com> wrote in >> news:1117724924.118207.181750 @g14g2000cwa.googlegroups.com: >> >> > Al wrote: >> > >> >>OK, I'll bite, which floating point form? >> > >> > I'm not allowed to say which floating-point IIR architecture we >> > (where I work) find gives the best results. Much has been written >> > on this topic, though, and a thorough literature search should >> > result in some pointers. >> > >> >>The problem with the floating point forms is that subtraction and >> >>addition kills you. For example, a big float - another big float = >> >>imprecise little float. This can be minimised to some extent by >> >>using a higher precision float such as the 40 bit version in the >> >>SHARC (32 bit mantissa & sign + 8 bit exponent) >> > >> > I've been thinking about the following little game: You and I each >> > write a program for the SHARC DSP that computes some specifiable >> > number of IIR biquads. You use the best available fixed-point >> > implementation, using the 32bit / 80bit fixed-point MAC unit. I use >> > our floating-point implementation using the 32bit / 40bit >> > floating-point MAC unit. Each of us must use 32bit precision >> > intermediate variables for the filter states (note that this gives >> > an inherent drawback for floating-point, because 40bit >> > floating-point filter states could be used with no additional cost >> > of the CPU time, and thus the floating-point performance could be >> > improved for free - but let's compare apples to apples). >> > >> > Now, each party gets to choose an arbitrary input signal (we can >> > define the input format to be 24bit fixed-point), and an arbitrary >> > set of biquad specifications. You choose an input signal and some >> > biquad filter specifications where you think the fixed-point >> > implementation shines and the floating-point implementation fails >> > miserably, and we each run that signal through our filter routines >> > and compare the outputs. Likewise, I get to choose a set of biquads >> > and a test signal, and again we compare the outputs of our >> > routines. >> > >> > We then measure the SNR induced by our respective routines (since >> > we know what the theoretical output should be) and compare the >> > results. I'm pretty sure I can ruin any fixed-point implemenation >> > with the appropriate filter specificiations (using two or perhaps >> > three biquads in series) and input signal, such that the >> > floating-point implementation will perform reasonably well with the >> > same test case (although I haven't tried this out yet). Do you >> > think you could do the same to show the converse :-) ? >> > >> >>Mark Allie gave a good presentation on this topic at last year's >> comp.dsp >> >>conference. >> > >> > Yes, I just read his talk on your CD (that was probably the best >> > spend $25 in my working life!). His discussion of error feedback on >> > DF1 and DF2 biquad architectures is very interesting. >> > >> > Regards, >> > Andor >> > >> >> I'm not sure I want to compare "black boxes" of IIR filters. I don't >> think the various direct forms in floating point will do as well as a >> DF I implemented in fixed point where a long accumulator is available >> (like every fixed point DSP chip). I have googled this topic >> extensively already. There are also a number of good AES papers on >> this topic, mostly written when Motorola 56K was still the most >> popular DSP family in audio. >> >> I do think it would be interesting to compare actual filters. >> Danville has web space available for anyone who wants to contribute >> an application note comparing IIR filter topologies implemented on >> the SHARC. >> >> The error feedback trick is almost free with the DF I. >> >> There may be some alternative Lattice based structures that work >> well. I haven't studied these very much. >> >> I think that we can agree that one of the nice things about the SHARC >> is that you can use whatever format you prefer. I like fixed point >> for IIRs & FIRs, floating point for FFTs and RMS detectors. >> >> Originally, I was going to create my own version of "Mark's talk". I >> managed to talk Mark into doing it instead and he did a great job. > > For me, quality and execution time are both important. I want to use > the cheapest filter type that gives me "acceptable" quality. So even > if there is some fancy filter topology available to make > floating-point as good as or better than fixed point, if it takes > significantly longer to execute than simple direct forms in > fixed-point, that's not an ideal solution. So a "black box" > comparison of filters would need to be augmented with benchmarks to be > useful for me. > > >I think the basic DF II floating point IIRs are cheaper (execution time) than the DF I filters. This is becoming less important all the time since MIPs keep increasing at a fairly fast pace and the differences are not necessarily large. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
Reply by ●June 2, 20052005-06-02
in article Xns9669C03C378B6aclarkdanvillesignal@66.133.129.71, Al Clark at dsp@danvillesignal.com wrote on 06/02/2005 19:53:> I think the basic DF II floating point IIRs are cheaper (execution time) > than the DF I filters.my experience with both the 56K and the SHArC (longer ago) was that it made no difference in the inner loop. perhaps the DF1 had a little more setup time than the DF2, but they were both 5 instructions per section in the inner loop. on the 56K, with simple noise shaping, it was 7 instructions. never did noise shaping on the SHArC.> This is becoming less important all the time since MIPs keep increasing > at a fairly fast pace and the differences are not necessarily large.they've been telling us that for decades, Al. it's like telling Donald Trump or Bill Gates that they made enough money and making more is increasingly less important. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●June 2, 20052005-06-02
"robert bristow-johnson" <rbj@audioimagination.com> wrote in message news:BEC51A07.7E5D%rbj@audioimagination.com...> in article Xns9669C03C378B6aclarkdanvillesignal@66.133.129.71, Al Clark at > dsp@danvillesignal.com wrote on 06/02/2005 19:53: > > > I think the basic DF II floating point IIRs are cheaper (execution time) > > than the DF I filters. > > my experience with both the 56K and the SHArC (longer ago) was that it made > no difference in the inner loop. perhaps the DF1 had a little more setup > time than the DF2, but they were both 5 instructions per section in the > inner loop. on the 56K, with simple noise shaping, it was 7 instructions. > never did noise shaping on the SHArC. > > > This is becoming less important all the time since MIPs keep increasing > > at a fairly fast pace and the differences are not necessarily large. > > they've been telling us that for decades, Al. it's like telling Donald > Trump or Bill Gates that they made enough money and making more is > increasingly less important.Right! Back in the "good ol' days" processing power was expensive, but you were only expected to run say a couple of biquads on 2 channels at 44.1kHz. Now, processing power is much cheaper, but you are expected to run maybe 31 biquads on 8 channels at 96kHz! So even now, there still is value in using the most efficient forms.
Reply by ●June 3, 20052005-06-03
robert bristow-johnson wrote:>in article Xns9669C03C378B6aclarkdanvillesignal@66.133.129.71, Al Clark at >dsp@danvillesignal.com wrote on 06/02/2005 19:53: > > > >>I think the basic DF II floating point IIRs are cheaper (execution time) >>than the DF I filters. >> >> > >my experience with both the 56K and the SHArC (longer ago) was that it made >no difference in the inner loop. perhaps the DF1 had a little more setup >time than the DF2, but they were both 5 instructions per section in the >inner loop. on the 56K, with simple noise shaping, it was 7 instructions. >never did noise shaping on the SHArC. > > > >>This is becoming less important all the time since MIPs keep increasing >>at a fairly fast pace and the differences are not necessarily large. >> >> > >they've been telling us that for decades, Al. it's like telling Donald >Trump or Bill Gates that they made enough money and making more is >increasingly less important. > >I am amused by all the people who keep telling me XML is fine, because bandwidth is so cheap and available these days. Then they ask me if I can recommend a codec with a lower bit rate than G.729 to help with their VoIP bandwidth issues. :-) Regards, Steve
Reply by ●June 3, 20052005-06-03
robert bristow-johnson wrote: ..> Andor, with one caveat, i think that Al's fixed-point implementation (with > 32-bit fixed-point signals and 80-bit accumulator)I purposedly suggested 24-bit fixed-point input signals. If you take 32-bit fixed-point input signals, the simple format conversion 32-bit fixed-point -> 32-bit floating-point already introduces quantisation distortion, at which point it becomes futile to further compare filter topologies.> would certainly beat your > floating-point implementation (with 32-bit floats and a 40-bit float > accumulator) regarding measurable quantization error. the caveat would be > the filters with gains that exceed 0 dB at some range of frequencies where > the fixed-point would be forced to saturate.I was assuming an overall gain through all biquads of less than one for the whole frequency range. I'm not exactly sure where or why you want to force saturation (it would be silly to do that with a floating-point topology). The point I was trying to make is that there are test cases (not too far away from real world audio equalization) where the fixed-point implementation will introduce high distortion, whereas the floating-point won't (by introducing high dynamic range in between biquads). I'm not sure (using 24bit fixed-point input signals) wether there is an appreciable difference in quantization distortion between the two filter topologies. Which fixed-point filter topology would you suggest for 24bit audio equalization using the SHARC DSP?> so, even if you're doing floating-point, *don't* use DF2.I'm not :-). Regards, Andor
Reply by ●June 3, 20052005-06-03
Al wrote:> I'm not sure I want to compare "black boxes" of IIR filters.Pity :-).> I don't think the various direct forms in floating point will do > as well as a DF I implemented in fixed point where a long > accumulator is available (like every fixed point DSP chip).As I said, no direct form for floating-point.>I do think it would be interesting to compare actual filters. Danville >has web space available for anyone who wants to contribute an application >note comparing IIR filter topologies implemented on the SHARC.Do you have SHARC source code for one of the fancy 32bit fixed-point IIR implementations? Such a comparison would really interest me as well.>I think that we can agree that one of the nice things about the SHARC is >that you can use whatever format you prefer.Yes, agreed. Regards, Andor
