No, I'm not talking about brokering an agreement between Democrats and Republicans in the United States. The title of this article refers to something of far greater significance to this community, namely the historical divide that exists between hardware and software developers.
Unfortunately, an us-versus-them mentality has developed separating those who write code and those who design the electronics that execute it. Given the symbiotic relationship between the two groups, this antagonism may seem odd to outsiders. To anyone who has ever been caught in the finger-pointing crossfire when the cause of an equipment failure is still an open question, the division into opposing hardware and software camps is a familiar scenario.
Many programmers are able to work at a level of abstraction that allows them to be indifferent to the finer points of the underlying electronics, as long as it has the speed and capacity they need. Likewise, many hardware designers can focus on achieving lower power and higher speeds without much concern for the high-level functions their chips or subsystems enable.
There is a sizable group of engineers who work much closer to the hardware-software boundary, however. These folks are often found working at the cutting edge of system performance or on tightly constrained applications. In such environments, the debate over performing functions in hardware or software still matters, with the answer changing over time in many cases.
Even though it's been many years since I last held a scope probe or a soldering iron, I have always considered myself a hardware guy. I persisted with this self-image as I followed my interest in digital signal processing from building special-purpose processors to studying the mathematics behind the algorithms. While I spent most of my time writing software to test and validate operations on computer-generated signals, I felt justified in my claim to affinity for hardware over software by the knowledge that any real-world application would require a hardware implementation. Today, of course, the implementation is more likely to utilize a programmable DSP chip than specially designed hardware.
In other areas as well, modern electronics manufacturing and EDA tools have made the work of electronic design look a lot more like programming. Whether you're designing at the chip or board level, your design is probably expressed as a set of instructions for a software-driven manufacturing process.
And then we have FPGAs — field-programmable gate arrays — taking over for ASICs in many applications. Does the inclusion of the word “programmable” in the acronym make anyone who works with FPGAs a programmer? Does it matter?
Instead of a sharp distinction between hardware and software functions, a truer picture of electronics is a hardware/software continuum with a rather indistinct boundary that tends to drift back and forth. Those who work in electronic design may come from one end of the spectrum or the other, but they must meet in the middle to find common cause and produce a functioning system.
Say, maybe this would be a good idea for Washington, too.
This article was originally published on EDN.