More than 6 billion processors of all types (4-bit to 64-bit plus DSPs) were sold in 2002. That astonishing number was actually off about 25% from the record volume of over 8 billion recorded two years earlier. Only about 100 million of those chips (just 1.5%) became the brains of PCs, Macs, and UNIX workstations born each year; embedded systems designers are the cause of the rest.

With about one new processor taking hold per person per year, it would be fair to say embedded systems are everywhere—or soon will be. The technology is only three decades old at this point—imagine the ultimate potential! Applications span the realm of imagination. Think of the number and diversity of insects and you’re on the right track.

There are so many different applications, and thus so many different types of embedded processors, in fact, that it’s becoming increasingly valuable in some circles to break that huge market up into more easily digested chunks. Applications can be grouped roughly into about seven key categories: communications, computer peripherals, industrial controls, military/aerospace, consumer, medical, and automotive, plus the obligatory catchall other/miscellaneous. These are termed vertical markets.

We should give some thought to what it is that ties all of the many vertical markets together. There is significant overlap between the work of designers of embedded systems for applications as seemingly diverse as consumer gadgets and military/aerospace systems. I suspect it is in this overlap that you find your identity as an embedded system designer.

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.