Archive for June, 2003

Firmer-ware?

Sunday, June 29th, 2003 Michael Barr

Too much of the terminology embedded systems engineers use in their everyday oral communications and written documentation is only vaguely defined—at 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 1 kb, 1 kB, or 1 KB 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 have since combined our years of 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 results, called the Embedded Systems Dictionary, should be available from CMP Books about the time you read this.

But this is not meant to be a sales pitch. I bring all this up only as background. You see, at a joint “book launch” attended by Jack and me at the CMP Books booth at the Embedded Systems Conference San Francisco, we had a very 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, Jack and I have both often seen the use of the term firmware somewhat restricted to either specifically DSP code or embedded software written entirely in assembly. When compiling the dictionary we agreed, however, that the definition ought properly to include code written in any programming language:

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 brought up a very 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 is 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.