CC270: Forward Progress

As you might have noticed, parts of this issue look a bit different than the publication you’re used to reading. You can see a slightly updated layout, some different colors, and a few new sections. We’ve made these changes to reflect where we are today and where we’re taking this magazine in the months to come. It’s all about forward progress. Here are the broad strokes:


We’re planning an exciting layout redesign for 2013. The layout will be modern, clean, and engaging, but its fonts and colors won’t distract you from what you’re reading—professional engineering content. Since the new layout is still an issue or two away, we’re presenting you with this freshened up issue to mark the transition to 2013. We hope you like the changes.


On page 20 you’ll find a new section that will appear frequently in the coming months. The purpose of our client profiles is to shine a light on one company per month and bring you an exclusive offer for useful products or services.


Last month we ran Steve Ciarcia’s final “Priority Interrupt” editorial. This month we’re introducing a new section, “Tech the Future.” The EE/ECE community is on the verge of major breakthroughs in the fields of microcomputing, wireless communication, robotics, and programming. Each month, we’ll use page 80 to present some of the fresh ideas, thought-provoking research projects, and new embedded design-related endeavors from innovators who are working on the groundbreaking technologies of tomorrow.


You’ll soon have Circuit Cellar’s 25th (“CC25”) anniversary issue in your hands or on your PCs or mobile devices. Here are just a few of the exciting topics in the issue: Circuit Cellar in 1988, design/programming tips, engineers’ thoughts on the future of embedded tech, and much more. It’s going to be a classic.

Well, there’s certainly a lot of publishing-related innovation going on at our headquarters. And I know you’re equally busy at your workbenches. Just be sure to schedule some quiet time this month to read the articles in this issue. Perhaps one of our authors will inspire you to take on your first project of the new year. We feature articles on topics ranging from an MCU-based  helicopter controller to open-source hardware to embedded authentication to ’Net-based tools for energy efficiency. Enjoy!

Issue 268: EQ Answers

Problem 1: A transformer’s windings, when measured individually (all other windings disconnected), have a certain amount of inductance. If you have a 1:1 transformer (both windings have the same inductance) and connect the windings in series, what value of inductance do you get?

Answer 1: Assuming you connect the windings in-phase, you’ll have double the number of turns, so the resulting inductance will be about four times the inductance of one winding alone.

If you hook them up out of phase, the inductance will cancel out and you’ll be left with the resistance of the wire and a lot of parasitic inter-winding capacitance.

Problem 2: If you connect the windings in parallel, what value of inductance do you get?

Answer 2: With the two windings connected in-phase and in parallel, the inductance will be exactly the same as the single-winding case. But the resulting inductor will be able to handle twice the current, as long as the core itself doesn’t saturate.

Question 3: Suppose you have a 32-bit word in your microprocessor, and you want to count how many contiguous strings ones that appear in it. For example, the word “01110001000111101100011100011111” contains six such strings. Can you come up with an algorithm that uses simple shifts, bitwise logical and arithmetic operators, but —here’s the twist—does not require iterating over each bit in the word?

Answer 3: Here’s a solution that iterates over the number of strings, rather than the number of bits in the word.

int nstrings (unsigned long int x)
   int result = 0;

   /* convert x into a word that has a '1' for every
    * transition from 0 to 1 or 1 to 0 in the original
    * word.
   x ^= (x << 1);

   /* every pair of ones in the new word represents
    * a string of ones in the original word. Remove
    * them two at a time and keep count.
   while (x) {
     /* remove the lowest set bit from x; this
      * represents the start of a string of ones.
     x &= ~(x & -x);

     /* remove the next set bit from x; this
      * represents the end of that string of ones.
     x &= ~(x & -x);
   return result;

Problem 4: For the purpose of timing analysis, the operating conditions of an FPGA are sometimes known as “PVT,” which stands for “process, voltage, and temperature.” Voltage and temperature are pretty much self-explanatory, but what does process mean in this context?

Answer 4: The term process in this case refers to the manufacturing process at the plant where they make the FPGA. It’s a measure of the statistical variability of the physical characteristics from chip to chip as they come off the line.
This includes everything from mask alignment to etching times to doping levels. These things affect electrical parameters such as sheet and contact resistance, actual transistor gains, and thresholds and parasitic capacitances.
These kinds of variations are unavoidable, and the P in PVT is an attempt to account for their effects in the timing analysis. The idea is to make the analysis conservative enough so that your design will work reliably despite these variations.

Contributed by David Tweed

Issue 266: EQ Answers

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.