The answers to the *Circuit Cellar* 266 (July 2012) Engineering Quotient are now available. The problems and answers are listed below.

**Problem 1—What’s the key difference between infinite impulse response (IIR) and finite impulse response (FIR) digital filters?**

Answer 1—An infinite impulse response (IIR) filter incorporates feedback in its datapath, which means that any particular input sample can affect the output for an indefinite (infinite) time into the future. In contrast, a finite impulse response (FIR) filter uses only feedforward in its datapath, which means that any given input sample can only affect the output for a time corresponding to the number of storage (delay) stages in the filter.

**Problem 2—Does the fact that the finite resolution of digital arithmetic effectively truncates the impulse response of an IIR filter turn it into an FIR filter?**

Answer 2—While it’s technically true that the impulse response of an IIR filter implemented, say, with fixed-point arithmetic is effectively finite, this has no real bearing on its classification in terms of either its design or application. It’s still an IIR filter for all practical purposes.

**Problem 3—The following pseudocode represents an implementation of a single-pole low-pass IIR filter, using 16-bit input and output values and a 24-bit internal accumulator and a filter coefficient of 1/256:**

# The 32-bit accumulator holds 16 integer

# and 16 fractional bits

$acc = 0x00000000;

# The input value is a 16-bit integer.

$input = 0xFFFF;

# Offset used for rounding the accumulator

# to 24 bits.

$offset = 0x80;

while (1) {

# acc = (255*acc + input)/256

$acc -= ($acc >> 8);

$acc += ($input << 8) + $offset;

# limit acc to 24 bits

$acc &= 0xFFFFFF00;

# output is integer part of acc

$output = $acc >> 16;

}

**An implementor of this filter complained that “the output never reaches 0xFFFF.” What was the flaw in his reasoning?**

Answer 3—The accumulator in this filter eventually settles at the value 0xFFFE8100. If you simply take the upper 16 bits of this, then the output value appears to be 0xFFFE. But if you properly round the accumulator by adding 0x00008000 before dropping the LSBs, then the output value is the correct value of 0xFFFF.

**Problem 4—The original implementor’s solution was to change the $offset value to 0xFF. Why did this work?**

Answer 4—Changing the $offset value to 0xFF effectively adds a bias to each input sample, which averages out to 0x00007F00 in the accumulator. The effect of this is to add the required rounding offset to the accumulator so that truncating the LSBs to create the 16-bit output value comes up with the correct answer.

.