Nuts & Volts - September 2005

In The Trenches

subroutines must be smarter than you.

Let’s look at two concrete examples. The first concerns a major ASIC (Application Specific Integrated Circuit) manufacturer. A number of years ago, I used ASICs, which can be thought of as consisting of a large number of small programmable logic devices with a fixed number of programmable interconnections. I had been developing these “by hand.” That is, I would define the logic and figure out the best way to interconnect them by myself. But, as the ASICs got more and more dense, developing them by hand became unworkable.

I bought very expensive development software that would design an ASIC from a schematic diagram. At the training class, I noticed that if a flip-flop wasn’t using the “Reset” function, it was shown as grounded in the schematic. This was odd because the flip-flop logic could be configured without a reset at all. Grounding it wasted an input to the logic device, as well as wasting interconnect resources to wire it to ground. Overall, this resulted in wasting about 10% to 20% of the ASIC. Therefore, anyone who employed this tool without understanding its implications could never fully use the power of the ASIC.

A potentially more serious example is with Anti-lock Braking Systems (ABS) on cars and trucks. Here, a computer detects when the wheels stop turning and briefly releases the brakes in order to prevent a skid. It sounds great and works pretty well most of the time.

With ABS, a good driver can generally come to a stop in about 10% less distance on dry pavement. However, on newly fallen snow, dirt roads, and some gravel roads ABS works very poorly. The stopping distance in increased by 100% to 200% over that of a good driver, because on these roads, you want the wheels to lock up. In lock-up, the snow, dirt, or gravel builds up in front of the tire and acts like a wedge or wheel chock. With ABS, the vehicle just rolls and rolls and rolls. You don’t skid, but you don’t stop, either.

There are software products to

SEPTEMBER 2005

automatically create websites. There are products that write interface code for you. There are products that claim to make everyone in the department an expert. Some are good, and some aren’t. All of them make every user equal. Unfortunately, this equality — whether it’s ASIC design or web-page layout or something else — is rarely better than average. And if everyone is an “expert,” then no one is. Besides, do you really want to rely on someone else to do your work for you?

Note that I am not against progress or new approaches. I appreciate novel ideas and products that save me time. It’s critical, however, to maintain control of every aspect of a project. It’s hard to believe that some stranger thousands of miles away knows my project better than I do. I also enjoy thinking for myself.

Lastly, by using pre-developed software products, you are helpless if anything goes wrong with that part of the project. If you didn’t know how to design it to begin with, how can you fix it? Control, experience, and training are elements of a project for which the designer is responsible. You can’t get these out of a box, any more than you can take a pill as a substitute for exercise.

Self-test

The need for self-test routines for any hardware interface can’t be overstated. If there is a bad component, it is critical to know this before trying to execute any instructions. With a jammed motor or a faulty sensor, the program can be a menace to lives and property.

Developing self-test code doesn’t have to be difficult. If you’ve been writing test code as you developed the software, most of the work is already done. All you have to do is assemble the modules into a logical framework. (Can anyone say bottom-up programming?) Of course, if you plan to use these test routines from the start, you can make the assembly effort easier still.

One important point often ignored is to make your error messages clear, and simple enough to be understood by anyone. There is nothing more frustrating than getting a cryptic error message that makes no sense. Tracking down the documentation isn’t always easy. For clarity, use the best available means that your hardware provides.

Another use for self-test routines is in production. Most self-test code measures some aspect of the hardware. Often this is useful to know during the fabrication of the product, as it