How do you define firmware? Fresh from a stint as the embedded systems lexicographer, Michael Barr thought the definition was all firmed up, only to find new definitions emerging, thanks to shifting design methodologies.
Too much of the terminology embedded systems engineers use in their everyday oral communications and written documentation is only vaguely definedat best. For example, terms like mutex, binary semaphore, and semaphore are often interchanged by software developers. In a related context, task, thread, and process are also tossed around as if they all represented the very same construct.
Hardware designers, too, are terminologically challenged. For example, does the new board need a 1kb, 1kB, or 1KB FIFO? Will it have flash or Flash, or is that flash really an EEPROM? There are also terms like emulator, which are overloaded with multiple meanings and must be expanded to be fully understood.
About a year ago, Jack Ganssle and I teamed up to finally do something about all this linguistic nonsense. We've since combined our experience as embedded hardware and software developers and precisely defined more than 2,800 terms used in the field of embedded systems design, development, and testing. The result is the Embedded Systems Dictionary, which should be available from CMP Books about the time you read this.
But this editorial is not a sales pitch. I bring the dictionary up as background. You see, at a book launch at the Embedded Systems Conference San Francisco, Jack and I had an interesting conversation with a hardware designer who considered the results of his Verilog coding to be “firmware.”
Neither Jack nor I had encountered such a usage of the term before. In fact, we've both often seen the use of the term firmware restricted to either specifically DSP code or embedded software written entirely in assembly. When compiling the dictionary we agreed, however, that the definition ought to include code written in any programming language. Here's what we decided on:
firmware n. Executable software that is stored within ROM. (Usage Note: This term is interchangeable with “embedded software” and sometimes used even when the executable is not stored in ROM.)
But this fellow raised an interesting point. At what point does hardware written in Verilog (or VHDL) and compiled into an executable binary format become indistinguishable from software written in C (or any other language) and compiled into an executable binary format? Is the hardware executable “firmer”-ware than the software executable? Or are they both just different flavors of firmware?
What will happen when, ultimately, a special-purpose C compiler can generate hardware? Or when a UML tool can automatically (and optimally) partition the description of a system's requirements into hardware and software and output a pair of binaries for the processor and the programmable logic in a single-chip platform FPGA?
At that point, will the hardware designers and software developers even be able to distinguish themselves from each other? As the line between hardware and software continues to blur, perhaps it's only the hours we keep and the forms of caffeine we favor that will belie our EE or CS backgrounds. That's when things will get really interesting.
A man after my own heart! As a veteran software/firmware developer, I've often plagiarized the realtor's expression…
“The three most important things in software development are nomenclature, nomenclature and nomenclature.”
That's one reason why I'd as soon try to turn an English major into a programmer as to start with some “computer engineering” doughnut. And while I'm on the subject, please help dissuade people (yourself included) from using the word 'methodology' when all they really mean is 'method'. Otherwise…
Keep up the good words.