If I use the term “software,” a variety of images might appear in the engineering audience’s mind. A software engineer might think of source code in his or her favorite programming language. A hardware engineer might think of a series of instructions to be executed on a Von Neumann architecture. A system designer might visualize a set of capabilities that are easy to modify in the field.

In high-tech, however, definitions are not well behaved. Things just refuse to stay in their boxes. Over time, inertia builds around a label or concept, only to be upset by status-quo-busting technological advances. For an idea such as “hardware,” it plays out like this: first, people come to some tacit agreement or understanding of what “hardware” means. Next, people become “hardware” experts, and educational tracks and job descriptions are built around the concept. We have “hardware” engineers and “software” engineers that go to different schools, attend different conferences, avoid each other’s cocktail parties, and almost never play on the same volleyball teams at the company picnic. System designers begin to plan their creations around the skill sets and development processes of hardware engineers and software engineers. The two become oil and water.

While we in the trenches may come to accept the definitions and labels as sacrosanct, the technology itself is much less myopic and forgiving. Today’s embedded technologies are a case-in-point. The line between “hardware” and “software” is rapidly blurring and even becoming irrelevant from a system design perspective. As this happens, the traditional roles and skillsets of hardware and software engineers are being challenged, and a new generation of designers is emerging as a result.

For years now, design with hardware description languages such as VHDL and Verilog has been the standard for custom digital design using ASIC and FPGA devices. Hardware engineers had to adopt the methodologies and techniques of software engineers such as debugging and source code configuration management. Conversely, software engineers wanting to get the best performance from high-speed hardware such as digital signal processors had to come to grips with concepts such as hardware parallelization, fixed-point math, and datapath optimization. System designers accustomed to thinking of “hardware” as the parts of the system that couldn’t change, “software” as the components that were easily modified, and “firmware” as something in-between, couldn’t resolve those definitions with, for example, field-reprogrammable hardware such as FPGAs.

It is the system designer’s concept of “hard” and “soft” that may ultimately cause us to retool and go back to school. In many embedded systems today, the success of standardized computing platforms and the standardization of peripheral interfaces has led to a dramatic decrease in physical hardware diversity. We see this effect on a macro scale every day – my laptop computer sometimes acts as a word processor, sometimes a television, sometimes a music library, and sometimes a communications device. Throughout these various deployments, the physical hardware never changes.

While this well-known polymorphism is obviously accomplished by a combination of software and plug-and-play peripherals based on standard interfaces, the flexibility offered by this new “softness” is pushing into the traditional hardware domain as well. Field-programmable hardware such as FPGAs allow even logic and embedded system architecture to be changed in the field without the modification of any physical hardware. For example, using embedded soft-core processors in an FPGA, the size and performance of processors, the mix of peripherals, and even the number of processors can be altered without modifying the physical hardware platform.

Taking advantage of this trend, a number of companies now offer production-ready embedded system boards that include processors, memory, basic peripherals, standard I/O interfaces, and FPGAs connected as generic, field-configurable custom hardware blocks. These ready-to-configure embedded systems could theoretically be used in anything from industrial controls to video processing systems to wireless networking. All the system design team needs to do is provide the application software, customize the reconfigurable hardware for any specialized I/O or signal processing that’s required, and attach the task-specific peripherals through the standard interfaces. Add a power supply, and it’s time to call in the mechanical folks to design your enclosure.

Increased softness has an impact on even our products themselves. For applications that require extreme performance, where software algorithms have to be accelerated into hardware, we have a need for hardware designs to be dynamically loaded, executed, and replaced just like software. In spaces like reconfigurable high-performance computing and software-defined radio, algorithm accelerators developed in highly-parallelized hardware load into their hardware implementation vehicles concurrent with software loading into program memory. For these applications, the processor architecture itself becomes soft, adapting to each particular algorithm or application. This capability ultimately enables us to do things that would otherwise be impossible with the state of conventional software and processor technology.

So, what are the new roles and realities in this era of enhanced softness? For the system designer, life becomes somewhat easier because the number of dimensions in the decision matrix is reduced. Factors like lifetime in the field take on new importance with the realization of the ability to fix bugs and add features and capabilities to a product even after it’s in the end-customers’ hands. Future-proof your physical hardware platform and your product could last considerably longer in the market and in the field, maximizing your return on development investment.

For today’s hardware and software engineers, you should get to know each other. You don’t need to rush out and place personal ads online or anything, but you should begin to acquire a better understanding of the other side’s tools and techniques. The required skills for your respective jobs are converging (against the grain in an age of increased specialization) and you’ll soon be working with (and competing against) a new generation of embedded engineers that are similarly skilled in both disciplines.