A scientific study of the problems of digital engineering for space flight systems,
with a view to their practical solution.

Definitions of Hardware, Software, and Firmware for Digital Logic Systems

Draft version 0.1: August 6, 2009.  Please send me comments.
Draft version 0.1a: August 13, 2009.  Added DO-254 definition of "software."


Digital logic systems, in general, can be subdivided into two disciplines: hardware and software engineering.

Flight systems contain products of the hardware and software engineering processes, and it is critical that both hardware and software components are of high quality. Hardware and software components are different and distinct, and the production of high quality components requires different and distinct skills, tools, techniques, processes, and most importantly, expertise and experience.

This white paper will provide some definitions of hardware, software, and firmware,  review a number of definitions, and provide some thoughts and commentary.

The Definitions

Hardware: The result of a process that defines the interconnection, configuration, and control of logic devices, input/output circuits, and other electronic devices and circuits.

Software: The result of a process that produces a set of computer instructions and associated data (e.g., addresses and operands) that is interpreted or simulated either by hardware or other software components.

Firmware: Software that is stored in a non-volatile memory device.


The definitions of hardware and software are intended to be independent of specific hardware or software technologies.

The term “firmware” is sometimes used to refer to the configuration of a logic device such as a Field Programmable Gate Array. Such usage is incorrect, misleading, and contradicts the definition of firmware above.  See "On the Use of the Term "Firmware" for further discussion.

The term “programming” is often correctly used to describe the process that, for example, opens fuses in logic devices such as PROMs or PALs, closes antifuses in devices such as PROMs or FPGAs, or loads contents into memory cells that control FET switches in an FPGA. “Programming” these hardware elements is distinct from and bears no relation to “programming” in the software process (where a “program” is written in a computer programming language, and then translated into a set of computer instructions and associated data).

A “computer instruction” is a statement that may be executed by an abstract machine and produces results that are independent of the implementation of any such machine. MIL-STD-1750A is an example of an instruction set architecture with many diverse implementations.

Definitions and Discussions of "Code"

Code: In software engineering, computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler, or other translator.  (IEEE Std 610.12-1990)

An older definition of code is "any set of machine language instructions." (Communications of the ACM, Vol. 6, No. 4, April, 1963).

An older (ACM, 1963) meaning of code is quite literal -- the "code" used to designate a computer instruction.  As compiler technology matured, and as translations improved, the usage of the term "code" meant the high level language source text.

Slang use of the word "code" is often used for the source text of a hardware description language (HDL).  While the syntax between software programming languages and HDLs are in some cases similar (e.g., VHDL and Ada), the meaning and use of the source languages are not.  For software programming languages, there is a translation from the source text to machine language instructions that, independent of the translation, will computationally give identical results.  For digital logic, this is not the case, and the output of the logic synthesizer is not code, but in effect a netlist -- it not simply a code to be executed on an abstract machine.  Indeed, machine produced netlists can result in poor quality, unreliable, and unsafe circuits by construction.  They can also act as a layer of abstraction, shielding the engineer from the design.  For mission-critical or safety-critical circuits, the designer must know how to control the logic synthesis process and how and when to look at the resultant circuits, typically with a netlist viewer.  Logic simulation and hardware testing can be insufficient to prove a design safe.

The source text describes the intended behavior of the circuit and the synthesizer generates digital logic circuits according to its algorithms and the direction of the user (e.g., constraints such as timing specifications, fan out limitations, target device size, etc.).

The digital logic community should not use the word "code" but instead uses a different term -- "description."  This is reflected in the formal language of the logic design community: The D in HDL and the D in VHDL represent descriptions.

The result of the slang use of the term "code" instead of "hardware descriptions" does not blur the line between hardware and software as so-called "Complex Electronics" proponents suggest.  Instead, it simply shows that one must pay attention to more than labels and slang usage.  The good logic designer does not program abstract algorithms to execute on a machine, but instead creates a proper description and guides the synthesizer to generate specific hardware structures. Experience has shown that designers that treat digital logic designs as software programmed in an HDL not only miss out on the opportunity to have "better" designs (e.g., performance, size) but can and do create circuits that are unreliable, and are incapable of detecting the design faults.

Some Sources and Context

Related Reading

Home -
Last Revised: February 03, 2010  --  Web Grunt: Richard Katz