Hi.
I'd like to implement 2nd or 3rd order IIR low-pass filter on C6747. For
the 3rd order version I get following coefficients from MATLAB:

>> [B,A] = ellip(3,1,60,10/83)

B =
0.005139381603929  0.006187906776077  0.006187906776077  0.005139381603929

A =
1.000000000000000 -2.530901747249838  2.242763702534123 -0.689207378524273

I know how to implement this in direct form I and II. But I'd like to
implement it in direct form II transposed because I will have to do it in
fixed-point later on (16 bit) and on ASIC. I have some troubles getting it
right on paper.
I have something like (for a 2nd order version):

s2(n) = b2*x(n) - a2*y(n)
s1(n) = s2(n-1)
s0(n) = s1(n-1) + b1*x(n) - a1*y(n)
y(n)  = s0(n) + b0*x(n)

But this would mean to me that I'd need 2 memories for s1, and 2 for s2.
Isn't there a way to do it with less memory usage and keeping the
transposed form?

And last question: any good hints for a book bringing together digital
signal processing and how to do implementations in hardware?

Thanks for all your help

Andreas

> a book bringing together digital
> signal processing and how to do implementations in hardware?

In german:
Pirsch "Architekturen der digitalen Signalverarbeitung" Teubner 1995
is a reasonably good introduction for students if found cheap (<30 EUR).

> I know how to implement this in direct form I and II. But I'd like to
> implement it in direct form II transposed because I will have to do it in
> fixed-point later on (16 bit) and on ASIC. I have some troubles getting it
> right on paper.

http://www.embeddedFORTH.de/temp/x.pdf
Would it be the right one in the picture ?

MfG  JRD

>> a book bringing together digital
>> signal processing and how to do implementations in hardware?
>
>In german:
>Pirsch "Architekturen der digitalen Signalverarbeitung" Teubner 1995
>is a reasonably good introduction for students if found cheap (<30 EUR).

Gut, dass ich ein bisschen Deutsch verstehe.;) Thanks. Will try to have a
look at it.

>> I know how to implement this in direct form I and II. But I'd like to
>> implement it in direct form II transposed because I will have to do it
in
>> fixed-point later on (16 bit) and on ASIC. I have some troubles getting
it
>> right on paper.
>
>http://www.embeddedFORTH.de/temp/x.pdf
>Would it be the right one in the picture ?

That's exactly what I mean.

>>> I know how to implement this in direct form I and II. But I'd like to
>>> implement it in direct form II transposed because I will have to do it
> in
>>> fixed-point later on (16 bit) and on ASIC. I have some troubles getting
> it
>>> right on paper.
>> http://www.embeddedFORTH.de/temp/x.pdf
>> Would it be the right one in the picture ?

> That's exactly what I mean.

Despite the optimism by Bingham i do not see the advantage
of the transposed version in general applications.
   The C6747 seems to be a float DSP. In float
quantization & structure do not matter yet.
   For 16 bit fixed integer the 3rd order elliptic LP
either would be two cascaded biquads. Or one IIR with
perhaps more internal wordlength to fight quanization and
limit cycles.
The direct form version shown on the left i think i see most
often for DSPs because it requires minimal RAM.
On a microprocessor i prefer the variant with more RAM
http://www.embeddedFORTH.de/temp/biquad.pdf
but easier arithmetic.

MfG JRD

On 08/31/2010 08:35 AM, Rafael Deliano wrote:
>>>> I know how to implement this in direct form I and II. But I'd like to
>>>> implement it in direct form II transposed because I will have to do it
>> in
>>>> fixed-point later on (16 bit) and on ASIC. I have some troubles getting
>> it
>>>> right on paper.
>>> http://www.embeddedFORTH.de/temp/x.pdf
>>> Would it be the right one in the picture ?
>
>> That's exactly what I mean.
>
> Despite the optimism by Bingham i do not see the advantage
> of the transposed version in general applications.
> The C6747 seems to be a float DSP. In float
> quantization & structure do not matter yet.

I must disagree.  For a given number of bits of storage, a signal in 
floating point will have worse quantization problems than a well-scaled 
signal in fixed point.  Why?  Because you waste bits in the exponent 
that could otherwise be used in the mantissa.

Floating point makes the math superficially easy, but it doesn't always 
make it trivial.  The traps are narrower and better hidden, but they're 
still there, they're still deep, and they have the same sharpened stakes 
in the bottom as with fixed-point math.

As an example, if you have a value of 0 in an integrator and you want to 
add 7e-9 to it, both IEEE single-precision floating point and 1R31 fixed 
point arithmetic will do the job -- in fact, the quantization noise from 
the floating point will be much better, at somewhere around 1e-16 
instead of 5e-10 for fixed point.  But now let the value of the 
integrator be 0.99.  The fixed-point arithmetic will still have the same 
quantization noise, but the minimum increment that the floating point 
will recognize has now gone up to 1.5e-8 -- which means that if you 
really need to resolve differences that small your integrator may get 
"stuck" there, instead of the perhaps proper behavior of slowly drifting 
up or down.

It is much easier to analyze the quantization noise effects with 
fixed-point math, because the quantization is always the same.  With 
floating point the quantization noise varies with the magnitude of the 
signals involved, making it a much more nonlinear problem, and therefore 
more of a pain in the behind.

Normally you can sidestep all of this with double-precision floating 
point -- until that one problem that won't admit it, or until someone 
takes your algorithm, implements it in single-precision floating point, 
then blames you for it not working.

So, floating point has its place, but it's no panacea.

> For 16 bit fixed integer the 3rd order elliptic LP
> either would be two cascaded biquads.

Or one biquad an one simple 1st-order filter.

> Or one IIR with
> perhaps more internal wordlength to fight quanization and
> limit cycles.

Given the locations of the poles of the transfer functions you'd need to 
add at least three more bits of precision per pole.  So perhaps you 
could get away with it -- but it's probably easier to just do the filter 
in cascade.

> The direct form version shown on the left i think i see most
> often for DSPs because it requires minimal RAM.
> On a microprocessor i prefer the variant with more RAM
> http://www.embeddedFORTH.de/temp/biquad.pdf
> but easier arithmetic.
>
> MfG JRD
>
>
>
>
>


-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Aug 31, 4:23=A0am, "ombz" <andreas.weiskopf@n_o_s_p_a_m.gmail.com>
wrote:
> Hi.
> I'd like to implement 2nd or 3rd order IIR low-pass filter on C6747. For
> the 3rd order version I get following coefficients from MATLAB:
>
> >> [B,A] =3D ellip(3,1,60,10/83)
>
> B =3D
> 0.005139381603929 =A00.006187906776077 =A00.006187906776077 =A00.00513938=
1603929
>
> A =3D
> 1.000000000000000 -2.530901747249838 =A02.242763702534123 -0.689207378524=
273
>
> I know how to implement this in direct form I and II. But I'd like to
> implement it in direct form II transposed

a good reference that is free is:

 https://ccrma.stanford.edu/~jos/filters/Transposed_Direct_Forms.html

> because I will have to do it in
> fixed-point later on (16 bit) and on ASIC.

i don't get it.  why would using a DF2T help over using a simple DF1?
(i would factor the filter into a biquad and a first order.)

> I have some troubles getting it
> right on paper.
> I have something like (for a 2nd order version):
>
> s2(n) =3D b2*x(n) - a2*y(n)
> s1(n) =3D s2(n-1)
> s0(n) =3D s1(n-1) + b1*x(n) - a1*y(n)
> y(n) =A0=3D s0(n) + b0*x(n)
>

it should be more like in reverse order of what you have put:

    y[n] =3D s1[n-1] + b0*x[n]
   s1[n] =3D s2[n-1] + b1*x[n] - a1*y[n]
   s2[n] =3D           b2*x[n] - a2*y[n]

that's how you do a DF2T.  now the problem, from my perspective, is
that s1[n] and s2[n] should be maintained as double-precision words.

a DF1 with one double-precision accumulator might be a better choice.
this also depends on how resonant the filter is and, if it's quite
resonant then how close are the zeros to those resonant poles.


> And last question: any good hints for a book bringing together digital
> signal processing and how to do implementations in hardware?

i don't know about implementations in hardware.  i s'pose your ASIC
library has code for a 16x16 -> 32 bit signed multiply.  and a 32-bit
adder.  or maybe, even if your signal is 16 bit, maybe your
coefficients need to be 20 or 24 bits.  in your own ASIC, there is no
need for the two word widths to be the same.

r b-j