On the Use of the Term "Firmware"
Draft version 0.1: August 6, 2009. Please send me comments.
The term "firmware" is widely used but its use is not precise. Indeed, the meaning of this term has changed significantly since it was first coined in 1967, its use is often imprecise and ambiguous, and it is often used in a slang sense, giving it yet another new meaning. While to a large extent this is a harmless and not uncommon use of language, engineers and managers may reach incorrect conclusions in error.
This white paper will cover the origin of the term "firmware," review a number of definitions, and provide some thoughts and commentary.
Avoid the term “firmware.” It does not aid in our discussion (perfectly valid in some contexts) and some people’s use of the term is confusing, since it conflates various different concepts. In mathematics, which is a tool of the engineer, two concepts defined by the same word are the same. In the English language, which is a tool of lawyers and politicians, two concepts defined with the same word can be different. I am an engineer.
First, some history on the term firmware. This discussion is not exhaustive by any means and the history of computing is a large topic! The term “firmware” has changed considerably since it was first coined, and it keeps on changing. So here goes …
Some Definitions and Usage Examples
1967: "Fourth-Generation Hardware," G.M. and L.D. Amdahl, Datamation 13 (1): 25-26
The term “firmware” was introduced to designate microprograms resident in the computer’s control memory. Note that “firmware” did not include the control memory itself; the current IEEE definition would. This use of this term is a bit archaic, as it is not now typically used in describing microcode. Indeed, not too many people write microcode anymore. We do, and have designed microcoded processors; we never described the microcode as “firmware.” Interestingly, in our last processor, for example, the microcode in the machine was reduced to logic equations and implemented by gates (multiplexors) inside of a gate array.
1981: Microprocessors and Programmed Logic, Kenneth L. Short, State University of New York at Stony Brook.
When a microprocessor system is used in a dedicated application, the control or application program is fixed and stored in ROM. Because changes in the control program are only necessary when the functions implemented by the system are to be altered, the control program in ROM is referred to as firmware rather than software. ...
1989: The Art of Electronics, Second Edition, Horowitz and Hill, 1989. Here is how they use the term firmware:
You can have the power of a microcomputer in the instruments and systems you design, by incorporating a microprocessor and some associated circuitry. In this sort of "dedicated" application the processor executes a fixed program you've burned into ROM ("firmware"), and there generally is no mass storage (disks, tape), terminals, etc. ... making changes and improvements is often as simple as writing new firmware. ...
1990: IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
The combination of a hardware device and computer instructions and data that reside as read-only software on that devices. Notes: (1) This term is sometimes used to refer only to the hardware device or only to the computer instructions or data, but these meanings are deprecated. (2) The confusion surrounding this term has led some to suggest that it be avoided altogether.
1992: “Munition Rocket and Missile Motor Ignition System Design, Safety Criteria for,” Department of Defense Design Criteria Standard, , MIL-STD-1901A
The combination of a hardware device and computer instructions or computer data that reside as read only software on the hardware device. The software cannot be readily modified under program control.
ISO/IEC 2382-1:1993 Information technology--Vocabulary--Part 1: Fundamental terms, 01.01.09
An ordered set of instructions and associated data stored in a way that is functionally independent of main storage, usually in a ROM. Note: The software cannot be readily modified under program control.
2000: "Design Assurance Guidance for Airborne Electronic Hardware," RTCA/DO-254.
This document does not attempt to define firmware. Firmware should be classified as hardware or software and addressed by the applicable processes. This document assumes that during the system definition, functions have been allocated to either hardware or software. RTCA DO-178/EUROCAE ED-12 provides guidance for functions that are allocated to implementation in software. This document provides guidance for functions that are allocated to hardware.
[DO-254 takes the approach to ignore the term "firmware" and instead treats hardware and software as distinct, and that distinct assurance methods and processes are used.]
2004: Software Safety Standard, NASA-STD-8719.13B w/ Change 1.
The combination of a hardware device and computer instructions and/or computer data that reside as read-only software on the hardware device.
ISO/IEC 12207:2008 Systems and software engineering--Software life cycle processes, 4.14
Combination of a hardware device and computer instructions or computer data that reside as read-only software on the hardware device.
My Proposed Definition:
Software that is stored in a non-volatile memory device.
The use of the term firmware, for the past several decades, as shown by the definitions and examples above, refers to software (computer instructions and associated data). The fact that this common usage differs from its initial use (for microcode) is not a significant issue: firmware is not currently commonly used to refer to microcode.
The current problem with the term firmware, as shown by the IEEE, is that its use is ambiguous. The IEEE defines “firmware” as both the software and the physical device which contains it (which differs from its original definition). The IEEE complains that some use the term “firmware” to refer to either the physical hardware device or the software, but not both. Such ambiguous use is at best a nuisance that can be easily be resolved as ultimately one will not mistake a physical device for an abstraction such as instructions and related data. And one will not confuse methods for dealing with the physical device (e.g., does this PROM have a fuse grow back problem?) with the software (e.g., is the code for an interrupt handler correct?)
Now, some usage and definitions of the term “firmware” refer to ROM or “read only memory” devices. The proposed definition uses the term “non-volatile memory device.” I used the term “non-volatile memory device” since in systems we build and fly today, that is an accurate term. While we have flown ROMs (e.g., Galileo to Jupiter launched in 1989) today we often fly antifuse-based PROMs and EEPROMs, for example. The common characteristic of these devices is that they are non-volatile.
And, interestingly (and I am trying to keep this interesting), another characteristic of EEPROMs (or flash which is also flown) is that they have slow write times and comparatively faster read times. In going back to the original paper that introduced the term “firmware,” the author writes (in 1967):
The memories are called read-only memories but, of course, the contents had to be written once in order to “load” the memory. Today, this is done as part of the computer fabrication process. For the fourth generation, extension to slow-write fast-read memory is anticipated.
OK, some things haven’t changed much in 42 years. J
Some people refer to the digital information that controls connections inside of a logic device (including mask programmed gate arrays, as well as field programmable gate arrays) as “firmware.” There is some motivation for describing the “firmness” of hardware designs. In its original 1967 usage, the control store was moving from a fixed micro-program fabricated as part of a machine to a “slow-write fast-read” implementation; this enabled field modifications or replacements of the micro-program without having to build a new machine, making it less “firm.” For digital logic systems, the slang use of the term “firmware” means that a change in the integrated circuit (e.g., mask programmed gate array, field programmable gate array, PAL, CPLD, etc.) can be made without changing the printed circuit board and was “less firm.”
Putting a software program into a non-volatile memory devices makes it "more firm" as the contents will not be corrupted when the power to a device, such as an instrument or appliance, is removed.
Therefore, one can talk about a software program or a hardware design having a degree of “firmness.” But a “more firm” software program is not the same as a “less firm” digital logic design. While “firmness” may be an adjective modifying or describing a noun such as software or hardware, it is not the defining identifier of the product.
Often we use appropriately configured FPGA logic devices for functions such as a voltage translator, a register, or a comparator. This indeed would be “less firm” than implementing the same function using SSI and MSI components soldered or welded to a printed circuit board. And even if described (third letter in VHDL) in a textual input format, one cannot state that such a design is either “firmware” or “software.”
Use of the adjective “firm” as a sole replacement for the complete term (whether or not they are describing hardware or software) makes no sense linguistically (and as such is a tool for politicians and lawyers) since it is ambiguous. It also makes no sense from either a computer science or electrical engineering perspective, as such a conflation of concepts would imply that software equals hardware, and that the techniques to develop and prove that a set of computer instructions and associated data is correct, are the same techniques as those to develop and prove that the connections, configuration, and control of logic devices are correct. While the overlap between the two disciplines is not null, they require distinct skills, tools, techniques, processes, and most importantly, expertise and experience.
Therefore, the term “firmware” should be avoided. It is ambiguous when referring to software, as the IEEE points out. However, this ambiguity pales in comparison to conflating the “firmness” of software (with its own ambiguity) with digital hardware logic designs.
Such ambiguity is not harmless and is more than a nuisance. In a number of cases, some individuals, with the zeal and religious fervor of politicians and lawyers, under the cover of the mathematical principle of transitivity, equate hardware with software, as they define both as "firmware."
The use of the term firmware should be avoided, unless one is referring to the storage of computer instructions and associated data stored in a non-volatile memory device. And in those cases, one should be careful and add redundant information to eliminate the ambiguity in usage, which the IEEE has identified. I am an engineer.
An Opposing View and Analysis
A different view is found in the "NASA Complex Electronics Guidebook for Assurance Professionals," December 31, 2004. This Guidebook describes its "anticipated audience," which is not one necessarily educated, skilled, and experienced in digital logic or electrical engineering:
This guidebook is primarily intended for software and quality assurance engineers who do not have significant experience with complex electronics. You don’t need a hardware background to understand the material in this guidebook. However, being familiar with embedded systems or flight hardware may help you absorb some of the concepts.
The author seeks to equate hardware with software through the term firmware, and desires that the definition of the term firmware be "updated."
How does Programmable Logic differ from Firmware? Firmware has various definitions, but the most common is that found in IEEE 610.12-1990: “The combination of hardware device and computer instructions and data that reside as read-only software on that device.” In other words, it is software that is placed in a read-only device, such as an EPROM, from which it may be read or copied. The EPROM acts solely as a storage device, much like a disk. Thus, firmware is simply stored software.
In the above paragraph, the author acknowledges the IEEE definition of firmware and provides a common sense description of firmware: "firmware is simply stored software."
Complex electronics, such as FPGAs and ASICs, are not firmware (as defined by IEEE 610.12), because what resides in them is not a software program. Instead, software is used to define the logic structure for a hardware device, which is what these devices become once they are programmed. These devices are better thought of as hybrid hardware/software devices, or “soft hardware”.
The author uses a non-standard term "complex electronics" in her argument. More importantly, the author correctly acknowledges that a software program does not reside in FPGAs and ASICs.
The author then runs into trouble when she states that "software is used to define the logic structure for a hardware device." While many professionals often use words and concepts in not a fully rigorous fashion (e.g., slang), here the author uses the slang to link software and hardware (see definitions of hardware and software).
"Software" does not define the logic structure of a hardware device; a text-based input provides a description of what the designer wishes the device to do (an exception to this is when, for example, structural VHDL is used, but that is a netlist, and bears no resemblance to a software language such as Ada, Pascal, or C). This text-based description is processed by a logic synthesizer, which outputs a netlist.
A schematic, filled with interconnected hard macros, does "define the logic structure for a hardware device." (Note: back end tools may make some typically minor modifications to the netlist).
In normal usage and application (e.g., not structural VHDL consisting of hard macros), there is little commonality to a text-based description input to a logic synthesizer and a graphic schematic that is input into a simple netlister.
The author also errs by stating that the device only becomes hardware after it is programmed. This is wrong, and dangerous: while a set of computer instructions and associated data is guaranteed to run functionally correctly on an Instruction Set Architecture, such is not the case for hardware. By viewing the interconnection of logic gates and hardware resources as software, leads one blind to the electrical engineering and architectural issues involved in the design of digital logic systems. By the time the device is "programmed" and considered "hardware" by the author, it is already too late. This is a serious, fundamental, and potentially dangerous flaw in the author's analysis and conclusions.
The author gets into further trouble when she encourages the reader to think of an FPGA or ASIC as a "hybrid/software device" and coins the expression "soft hardware." A gate array, in slightly simplified terms, is an array of gates, with each gate being a universal logic element. The Apollo Guidance Computer, for example, was constructed solely of three-input NOR gates. Mask programmed gate arrays are often arrays of two-input NAND gates. Xilinx FPGAs are based on lookup tables. Actel FPGAs are based on a multiplexor. Viewing these array-based logic devices for what they are -- arrays of universal logic elements -- the logic designer is presented with a generally similar design problem. Indeed, the distinction of how the connections between logic elements is made is not what defines one device as hardware or another as software (or a hybrid known as "soft hardware.") Indeed, connections can be made using welds, solder, traces on a printed circuit board, the programming of an antifuse, the state of an SRAM cell biasing a FET switch, etc. While important, particularly towards the timing analysis and clock distribution networks for a design, they do not move a digital device into the realm of software.
However, the type of connection can determine the "firmness" of a logic design implementation. Reprogramming SRAM-type storage cells would be "less firm" or "softer" then having to cut traces, lift leads, replace components, and install jumper wires. But a "less firm" hardware design does not equate with a "more firm" software device. Grouping these together is wrong, and leads to incorrect conclusions.
The author concludes this section as follows:
Programmable logic devices blur the hardware/software boundary. The IEEE definition of firmware does not encompass these devices. Either an updated definition of firmware needs to be adopted by NASA, or a new term needs to be coined to describe these devices.
Programmable logic devices do not blur the boundary between hardware and software in typical usage of these terms. While in modern devices software, running on workstations and PCs, play an increasing role in the design of these large devices, one cannot confuse computer instructions and associated data that is designed to execute on a mathematical concept known as an instruction set architecture with a connection of gates, their configuration, and control of other circuits and devices.
The author argues that the term firmware should be extended to cover digital logic devices. That would be an error, as the term firmware is already ambiguous, as publicly documented by the IEEE. It does not serve the electrical engineering, software, or assurance communities to aggravate the problem, and add to the ambiguity of the term "firmware."
The author also argues that a new term need be coined. There is no need for such a term, they are digital logic devices (note that there are mixed signal devices, as well as processors internal to these devices, but that is separate and severable). "Firm" is a reasonable adjective for "software", resulting in "firmware." "Programmable" is a reasonable adjective for logic devices, resulting in the widely used term, "programmable logic."
Last Revised: February 03, 2010
http://twitter.com/klabsorg -- Web Grunt: Richard Katz