Tuesday, April 27, 1999

Words of Wisdom

This article appears in slightly different form in the March/April 1999 issue of IEEE Micro © 1999 IEEE.

This time I look at two thin books in which highly respected engineers offer words of wisdom to undergraduates and experienced engineers alike.

Logical Effort: Designing Fast CMOS Circuits by Ivan E. Sutherland, Robert F. Sproull, and David Harris (Morgan Kaufmann, San Francisco CA, 1999, 240pp, ISBN 1-55860-557-6, www.mkp.com, $42.95)

Ivan Sutherland is the recipient of both the ACM Turing Award and the IEEE Von Neumann Medal. He and Bob Sproull are Sun fellows (and vice-presidents). Both are highly acclaimed experts in the design of graphics hardware and software. They published the theoretical kernel of this book in a paper in 1991.

David Harris teaches engineering at Harvey Mudd College. After developing many of the same techniques independently, he persuaded Sutherland and Sproull to let him rework their unpublished notes into this book.

Logical effort is a theoretical construct that measures the relative cost of computation inherent in the circuit topology that implements a logic gate's function. A logic gate may contain many transistors, and MOS transistors in series conduct electricity relatively poorly. Thus, some logic gates require substantially more logical effort than others.

Electrical effort is the ratio of the logic gate's output to input capacitances. The product of logical effort and electrical effort, plus a term that represents the parasitic capacitance of the logic gate, gives a relative measure of the time it takes a signal to pass through the logic gate.

Because input capacitance depends largely on the sizes of the transistors that make up the logic gate, this analysis allows the authors to decompose signal delays into separate logical, transistor size, output load, and parasitic terms. The authors recognize that this is an approximation, but it is a useful one. It allows them, through relatively elementary mathematics, to arrive quickly at circuit designs that they can prove are close to optimal speed.

The authors know that many good circuit designers have independently discovered some of their results, and they acknowledge that there are many heuristics that produce good results. Nonetheless, many designers -- especially beginners -- rely on the "simulate and tweak" method, and for those designers, the authors' method is a big improvement. As Sutherland says about the original work he did on this method in 1985, "I resorted to calculus for lack of circuit simulation tools. Instead of computing I had to think about the problem, a formula for success that I recommend highly."

This leads to one of the reasons the authors give for reading this book. It gives you a new way to think about circuits -- new rules of thumb to help you build your intuitive understanding. I think there is another good reason to read it. It's a wonderful example of how world-class engineers think about a problem. The problem is easy to understand, and with a little effort, most designers can follow the authors' reasoning and understand their results.

The book is excellent for students, because it works through a many examples in great detail. Exercises encourage you to work through examples on your own -- the best way to incorporate the method into your intuitive thinking about CMOS circuits.

Like many good books nowadays, this one comes with its own website: www.mkp.com/Logical_Effort. There you can find answers to exercises, an extensive design example, and some software.

If designing circuits interests you at all, I think you'll appreciate this book.

The Practice of Programming by Brian Kernighan and Rob Pike (Addison Wesley, Reading MA, 1999, 288pp, ISBN 0-201-61586-X, 800-822-6339, tpop.awl.com, $24.95)

There are few software engineers more distinguished than Brian Kernighan and Rob Pike. Both have been at Bell Labs for as long as I can remember. Pike was an architect of the Plan 9 and Inferno operating systems. He works on software that makes writing software easier.

Kernighan and Pike's last book, The Unix Programming Environment (Prentice-Hall, 1984) is a well known classic. Kernighan is also known as the K in K&R, the name by which many refer to The C Programming Language (Prentice-Hall, 1978), an even more classic work he coauthored with Dennis Ritchie. My favorites, though, are the works Kernighan coauthored with PJ Plauger: The Elements of Programming Style (McGraw Hill, 1974) and Software Tools (Addison-Wesley, 1976).

Steve McConnell's Code Complete (Microsoft Press, 1993) addresses the fact that most programmers know only scattered bits of the large body of practical knowledge about programming. They often go directly from school, where they don't learn practical programming, into isolated jobs without mentoring or apprenticeship. McConnell's answer to that problem is an 877-page systematic survey of professional programming practices. You can go off by yourself and, given enough time, read and understand everything in it.

Kernighan and Pike's book covers many of the same topics, but it is much shorter. The authors aim at being clear and concise, but they don't waste time explaining things you can find easily elsewhere and should probably already know anyway. To get the most out of the book, you should read it with the help of an experienced programmer or teacher who can explain some of the subtleties.

The cover of the book bears the message "simplicity, clarity, generality," and the book exemplifies those principles. Seven of the nine chapters have one-word titles. A section on error handling is called Abort, Retry, Fail? The text does not mention that famous message, but the error-handling principles it teaches help you make the connection.

It's hard to summarize a book that is already clear and concise. An appendix contains three pages of one-line statements of rules that appear in the book. They range from generalities (be consistent, be accurate, stick to the standard) to specifics (use else-ifs for multi-way decisions, parenthesize the macro body and its arguments).

The rules the authors list under debugging and testing are all generalities. This illustrates one of the difficulties of trying to teach programming from a book. Testing and debugging depend heavily on the facts of the case and the details of the environment. It is much easier to learn these skills at the side of a master programmer who is willing to think out loud while testing real programs and pursuing real bugs. Given that limitation, the authors do an excellent job of pointing out ways to make testing and debugging easier and more systematic.

Programming is a form of communication. The programmer communicates with the machine or operating system and with other programmers. Programs often communicate with each other. The book's chapters on style, interfaces, portability, and notation make you aware of these issues and give you tools to ensure that you and your programs communicate clearly and efficiently.

Programming languages are the foundation of programming communication. In one chapter the authors solve the same problem five times, using a different programming language each time. Today's top programmers must know many languages and know how to choose the right language for each job.

Computer books come and go -- usually quickly. Very few become classics. This one won't go quickly. I think it will become a classic.