"Software-ization" may be a made-up word, but it accurately describes the trend in design. Today, hardware is what is left over when you finish with the software. With the growing popularity of reprogrammable hardware, such as FPGAs, and software techniques, such as digital-filter design and modulation, the software logic is becoming the most important aspect of a design, making the world increasingly "software-ized."

The increased focus on software design is evident in the design teams of today. According to Venture Development Corp, the average software-design team now numbers 3.9 members versus 2.3 for hardware-design teams (Reference A). The trend toward software-ization does not end there: The need for programmable hardware is evident in the increasing number of programmable devices, such as FPGAs (Reference B). The need is clear: Designers want to reprogram their applications, which makes economic and efficiency sense. Managers prefer this approach because it means that you get more out of the hardware you purchase because you can reprogram it as specifications change, efficiently develop prototypes, and add features to deployed systems.

Another important angle emphasizing the need for software-ization is related to the "long-tail" business model (Figure A). The long tail describes how future business focus should be on "odd jobs" or millions of niche markets versus a few high-volume vertical markets. Examining vertical markets, such as cellular-telephone or plasma-television designs, you find plenty of reference designs specific to those markets. Those working in the long tail on applications from laser wrinkle removers to underwater surface crawlers have no access to reference designs; nevertheless, the expectations of products delivered in the long tail do not diminish. You still have the same pressure to deliver high quality and innovation but without the tools or reference designs available to help. At this point, software-ization couples with an integrated platform to help design engineers. Software-ization dynamically adjusts to the changing world of odd jobs. You need an integrated, off-the-shelf platform, so that when you implement the design in hardware, you need not hire any more hardware engineers (Figure B).

Another benefit of using software-ization with off-the-shelf hardware platforms becomes evident when examining test challenges with products in lower volumes. Tests on high-volume cell phones are thorough and costly, but high sales volume offsets this time and expense. However, with lower volumes of, say, 10 to 100 annually, it no longer makes economic sense to perform corner-case testing, but you still need a high-quality product. The more efficient approach is reuse. Tested, off-the-shelf hardware platforms often come with industrial certifications, including international safety, EMC (electromagnetic-compatibility), shock, vibration, and environmental ratings. So, you can reuse this tested equipment and incorporate certified products into your design process for a much lower cost.

What does software-ization look like, and what does it mean to have software-program hardware? Software to program hardware must include syntax and semantics with explicit notations for expressing time and concurrency—primary attributes of hardware. Traditional, sequential programming languages do not exhibit these behaviors, making these applications difficult to develop.

Using the right software tool to program hardware is happening in many applications, including custom-test digital protocols with FPGAs; communications logic running in a DSP; and remote updating of deployed, embedded systems on a real-time microprocessor.

One of the most common design tasks—digital-filter modeling and design—takes advantage of software-ization. The use of digital filters eliminates a number of problems that their analog counterparts face. In software, you can attenuate unwanted signal elements such as noise caused by electrical components and environmental effects, apply antialiasing algorithms to test data, and reduce sample sets with decimation. Digital filters find use in a variety of applications ranging from machine-condition monitoring and animal-vocalization detection to seismic signal decomposition and audio special effects (Figure C). Once you design your filter with an integrated hardware platform, you can implement the filter without knowing the hardware details—another example of the beauty of software-ization.

Software-ization is a good thing for everyone. It means more manageable projects, lower hardware costs due to more reuse, and an easier path to more innovation due to the inherent ability to more quickly experiment, iterate, and implement.

The "software-ization" of an enormous range of applications has brought more features and lower product costs to end users and shorter development times and lower product-lifetime-management costs to manufacturers. By and large, these applications exploit the processing power of microprocessors, microcontrollers, and DSPs. They depend on the availability of off-the-shelf programmable logic that economically provides greater processing power than the application's peak processing requirements demand.

Real-time applications as disparate as motion control, communications, and image processing test the limits of software implementations running on general-purpose programmable hardware. In these applications, complex processing requirements combine with high data rates or signal bandwidths to drive hardware usage and code complexity to uneconomic extremes.

In motion control, for example, high-speed control loops depend on real-time vector-transform calculations to determine power-switching times within a rotating frame of reference. A second, inverse, set of transforms operates on the motor's feedback signal. The complexity of these calculations exceeds the processing bandwidth of low-cost processors based on traditional architectures. The "bigger hammer" approach—using more powerful general-purpose processors fabricated on faster semiconductor processes—doesn't sufficiently improve computational efficiency and can drive both silicon and software-development costs to noncommercial levels.

Still, the allure of programmable loops and the accompanying benefits to OEMs of reduced development cost and time savings merits the rethinking necessary to achieve high bandwidth and low cost. Though traditional microprocessor, microcontroller, and DSP architectures may not be best for these applications, custom-hardware implementations often poorly support rapid product-development cycles or easy design maintenance.

As high-speed communications and image processing have done before them, motion-control applications are taking advantage of computational engines—application-specific logic—that serve as a programmable interface between an application-management layer and a real-time process. Computational engines offer a middle ground between software-ization and fixed-topology hardware that benefits OEM designers by reducing both development time and project risk in these computationally intensive real-time applications.

At the real-time-process interface, computational engines efficiently support high-bandwidth control loops through application-specific hardware peripherals, low-level firmware, and vendor-provided algorithms. OEM-configurable computational resources allow product developers to customize the engine's resources in ways that parallel the high-level coding of general-purpose programmable logic. In the case of the engine-based implementation, however, the development environment can support programming in application-relevant terms.

Visual-programming environments can go a step further, allowing product developers to specify signal flows between computational blocks without coding per se. Such high-level constructs do not preclude OEMs from customizing the lower level operating algorithms or developing new algorithms from scratch, but they do provide for significantly shorter development and substantially improved code reuse. This balance between hardware and software resources promotes rapid prototyping, quick development of derivative products, and low-cost design maintenance.

On the application-control end of the design, the engine can present an intelligent interface to either a co-integrated or co-embedded microcontroller. The small microcontroller can efficiently manage the user interface—panel switches and displays—and direct the outermost application-control loop. The advantage of this functional segmentation between the microcontroller and the real-time engine is that the interface between them can use physical quantities instead of coded coefficients. Again using the motion-control example, this interface can express shaft speeds in rpm or torque limits in newton-meters. This layer of abstraction separates the application-control development from all of the details of managing the motor in real time.

Integrated design platforms, comprising the real-time engine, vendor-provided routines, hardware peripherals, and development environment, capture highly specialized hardware-engineering expertise. They also allow the OEM to build upon the resource by customizing or developing in-house functional and algorithm libraries. Most important, this approach reduces the OEM's need to reinvent the technological wheel and instead promote a focus on those design areas that best differentiate the product.

In the 1950s, the computer went from laboratory curiosity to a hugely expensive but useful business tool. The ’60s saw the mainframe’s role grow tremendously; meanwhile, minicomputers from Digital Equipment, Honeywell, Raytheon, Data General, and many others put computing into the reach of new kinds of customers who didn’t possess the deep pockets that made IBM salesmen smile. But minis were still so expensive that they rarely replaced dedicated circuitry except in specialized applications. Even by 1970, DEC’s PDP-8/E had a base price of $6500, which is equivalent to approximately $34,000 in today’s dollars.

In 1972, EDN reported on the advent of the first microprocessor, Intel’s famous 4004, which debuted at $100 for just the chip itself (Reference). Though a useful computer needed a tremendous amount of support circuitry, clever engineers realized that this new pricing node made it reasonable to dedicate processors to specific tasks. The embedded-system industry was born.

Better technology and the magic of volume manufacturing pushed prices even lower. By 1974, Texas Instruments’ TMS1000, the first microcontroller, nearly delivered on the promise of a “computer on a chip.” Two years later, Intel’s 8048 truly shrunk a complete machine into a single IC—one whose legacy persists today in the 8051 family. In 5 billion years, when the sun grows dark, someone, somewhere, will be writing 8051 code.

Managers bought into the notion that software was free. Couple free—other than astronomical development and support costs—code with nearly free hardware, and it makes sense to substitute processors for dedicated circuits. Early embedded systems replaced industrial-automation equipment such as PLCs (programmable-logic controllers), which used big arrays of expensive cam timers and relays to control factory equipment. These mechanical contraptions were programmable; a technician could alter the position of cams to change timing—for instance, to select when to dispense liquid from a nozzle. Infinitely malleable software was a natural and cheaper substitute.

In the ’60s, EEs often used analog circuits to perform calculations that were prohibitively expensive using logic. Some instruments, such as colorimeters, had to compute the classic “distance” equation: the square root of the sum of the squares of various parameters. It’s not hard to put a transistor into the feedback loop of an op amp to cheaply compute square roots, but doing a square root with TTL components is tough. Yet, these analog circuits had poor resolution and were subject to drift. The marketplace found that a software approach was more economical and stable and could output as much precision as an application demanded.

Instrumentation vendors found that they could generate better data by applying software-smoothing algorithms to perpetually noisy analog inputs. These algorithms had similar effects on outputs. Old-timers remember using grease pencils on the faces of oscilloscopes’ CRTs to “log” waveforms. Though analog storage tubes offered some relief, today’s smart scopes not only offer plenty of storage options, but also perform math on the data to figure frequency, rms amplitude, and more. Some run an FFT to rotate time data into the frequency domain.

Onboard software replaced ever-vigilant ground controllers so spacecraft operating many light-hours away could autonomously perform complex maneuvers.

Legislation influenced design. Automotive carburetors yielded to fuel-injection systems whose software monitors many inputs to meet emission standards. Energy Star appliances use smart code to reduce power consumption, and intelligent controllers at power plants limit coal consumption by calculating optimum burn ratios.

Software is no longer just a substitute for analog and digital circuits. Entire classes of features and products just couldn’t exist without the complexity that code enables. Cell phones, iPods, digital cameras, and more would be as large as city blocks if designers implemented them in hardware.

Ironically, a new trend is now replacing software with hardware. FPGA vendors offer embedded processors whose instruction sets you can fine-tune to meet an application’s needs. At least one vendor offers a tool that converts snippets of slow code into speedy FPGA hardware.