标签: circuit design

Arguing is something that people get into when they are emotionally involved, or maybe even as recreation, as so wonderfully captured by the classic, timeless Monty Python "Argument" sketch (click here for a summary of the sketch; it also has links to the script and a video clip.) Engineers even like to sometimes argue technical issues "after hours", while unwinding at the local snack shop, watering hole, or conference. But what should engineers argue about: The "best" processor? The "best" operating system or language? Which debug tools to use in various circumstances? Yes, those are viable topics, but I'd like to propose some bigger, broader topics for engineers to debate with their fellows. To help you all get started, I have included links to some previous columns on these topics:  • What went right (or wrong) with Space Shuttle program, and why didn't it live up to its initial promise (see here )?  • Is spread-spectrum clocking a clever engineering technique, or is it a down-and-dirty cheat (see here )?  • Should we be switching to Daylight Savings Time, or is it an outmoded concept from an era now gone, and which now brings no real benefit?  • Is circuit design—as distinct from IC design—still a widely needed skill (see here )?  • Should we replace the standard car steering wheel with a joystick (see here )?  • Will the outcome of Texas Instruments' acquisition of National Semiconductor be a net gain, loss, or neutral?  • Is IBM's Watson an indication of how far computers have come in replicating the human brain, or of how little we actually know about the brain?  • And the big one: should "climate science" and even be considered as science, in the classical, traditional meaning of the term "science"? Remember, it's OK to argue based on your personal beliefs, but it is also good to try to argue both sides of an issue—it's an important mental exercise. Are there other "big picture" topics you would suggest engineers have a spirited argument about?  

Arguing is something that people get into when they are emotionally involved, or maybe even as recreation, as so wonderfully captured by the classic, timeless Monty Python "Argument" sketch (click here for a summary of the sketch; it also has links to the script and a video clip.) Engineers even like to sometimes argue technical issues "after hours", while unwinding at the local snack shop, watering hole, or conference. But what should engineers argue about: The "best" processor? The "best" operating system or language? Which debug tools to use in various circumstances? Yes, those are viable topics, but I'd like to propose some bigger, broader topics for engineers to debate with their fellows. To help you all get started, I have included links to some previous columns on these topics:  • What went right (or wrong) with Space Shuttle program, and why didn't it live up to its initial promise (see here )?  • Is spread-spectrum clocking a clever engineering technique, or is it a down-and-dirty cheat (see here )?  • Should we be switching to Daylight Savings Time, or is it an outmoded concept from an era now gone, and which now brings no real benefit?  • Is circuit design—as distinct from IC design—still a widely needed skill (see here )?  • Should we replace the standard car steering wheel with a joystick (see here )?  • Will the outcome of Texas Instruments' acquisition of National Semiconductor be a net gain, loss, or neutral?  • Is IBM's Watson an indication of how far computers have come in replicating the human brain, or of how little we actually know about the brain?  • And the big one: should "climate science" and even be considered as science, in the classical, traditional meaning of the term "science"? Remember, it's OK to argue based on your personal beliefs, but it is also good to try to argue both sides of an issue—it's an important mental exercise. Are there other "big picture" topics you would suggest engineers have a spirited argument about?  

In the recent years, I have believed—and told many others—that the age of circuit design is over. By "circuit design", I don't mean IC design: I mean taking ICs, discrete devices, and passive components, then integrrating and configuring them to create the distinctive topology which addresses multiple design issues, while meeting an application's requirements. Why have I felt this way? Because it seems to me that the circuit-design challenge and battle has been largely, although not entirely, won by the IC vendors. That's the case even in the subtle areas of data acquisition and test/instrumentation, where the analogue front end must be carefully tailored to the transducer as well as operating conditions. Much of circuit design now consists mostly of selecting the right ICs, being sure that they interface properly with each other and the I/O, and then providing software to make them execute their roles properly. For example, you can now get high-performance op amps and instrumentation amps (in-amps) for modest cost. No longer do you need to select passives and carefully match temperature coefficients or worry about drift. In many cases, they are now embedded in the IC and thus inherently matched, or the IC has some clever scheme that cancels out many drift errors. Further, vendors offer reference designs and development kits which feature tested and verified circuits for many common, and even some unusual applications. But as with so many of my pronouncements, I was wrong. Here's why: I recently saw a design and actual prototype done by Jim Williams and Omar Sanchez-Felipe of Linear Technology Corp. Jim's formal title is Senior Scientist, but that's somewhat misleading: he is among the preeminent analogue-circuit designers in the world, with a career which spans 40+ years. I still marvel at his first major published design for a portable scale for the MIT nutrition lab, which had to resolve to 0.1 oz, never need calibration, and be built using only standard, off-the-shelf components. It was—and still is—a marvelous example of understanding every subtle source of signal-chain error and then figuring out how to minimise or cancel each one. What have Jim and Omar done? They started with what seems to be a simple, straightforward way to measure temperature called acoustic thermometry, which is based on the consistent variation in the speed of sound as temperature changes. In principle, this should be an easy circuit: all you need is to take an ultrasonic transducer, pulse it, measure the transit time of the echo, do a simple calculation, and you are all done. What's the big deal? But principle is not reality; it's not even close to it. The final circuit required careful management of low and high voltages, pulse timing, signal lockout, and many other factors, plus physical placement issues. You can read the full details in their Application Note 131, An Introduction to Acoustic Thermometry here . While you are doing that, I will use this application and its physical realisation in an actual circuit design as a constant reminder that there still is room for what we understand in our gut as The Existential Pleasure of Engineering (to use the title of Samuel C. Florman's excellent book).

In the recent years, I have thought—and told a lot of people—that the age of circuit design is over. By "circuit design", I don't mean IC design: I mean taking ICs, discrete devices, and passive components, then integrrating and configuring them to create the distinctive topology which addresses multiple design issues, while meeting an application's requirements. Why have I felt this way? Because it seems to me that the circuit-design challenge and battle has been largely, although not entirely, won by the IC vendors. That's the case even in the subtle areas of data acquisition and test/instrumentation, where the analogue front end must be carefully tailored to the transducer as well as operating conditions. Much of circuit design now consists mostly of selecting the right ICs, being sure that they interface properly with each other and the I/O, and then providing software to make them execute their roles properly. For example, you can now get high-performance op amps and instrumentation amps (in-amps) for modest cost. No longer do you need to select passives and carefully match temperature coefficients or worry about drift. In many cases, they are now embedded in the IC and thus inherently matched, or the IC has some clever scheme that cancels out many drift errors. Further, vendors offer reference designs and development kits which feature tested and verified circuits for many common, and even some unusual applications. But as with so many of my pronouncements, I was wrong. Here's why: I recently saw a design and actual prototype done by Jim Williams and Omar Sanchez-Felipe of Linear Technology Corp. Jim's formal title is Senior Scientist, but that's somewhat misleading: he is among the preeminent analogue-circuit designers in the world, with a career which spans 40+ years. I still marvel at his first major published design for a portable scale for the MIT nutrition lab, which had to resolve to 0.1 oz, never need calibration, and be built using only standard, off-the-shelf components. It was—and still is—a marvelous example of understanding every subtle source of signal-chain error and then figuring out how to minimise or cancel each one. What have Jim and Omar done? They started with what seems to be a simple, straightforward way to measure temperature called acoustic thermometry, which is based on the consistent variation in the speed of sound as temperature changes. In principle, this should be an easy circuit: all you need is to take an ultrasonic transducer, pulse it, measure the transit time of the echo, do a simple calculation, and you are all done. What's the big deal? But principle is not reality; it's not even close to it. The final circuit required careful management of low and high voltages, pulse timing, signal lockout, and many other factors, plus physical placement issues. You can read the full details in their Application Note 131, An Introduction to Acoustic Thermometry here . While you are doing that, I will use this application and its physical realisation in an actual circuit design as a constant reminder that there still is room for what we understand in our gut as The Existential Pleasure of Engineering (to use the title of Samuel C. Florman's excellent book).