Simple Example Highlights Hardware-Software Tradeoff
How does one really decide between a hardware vs. a software design implementation? Early in a product’s life cycle, designers must consider high-level architectural issues like power, performance, area and cost. But a high-level view is just an abstraction of the – as yet uncertain – lower-level details. A good designer understands both the high- and the low-level points of view.
At the lowest level in a hardware-software tradeoff decision, the designer must decide what system functionality will be realized in software blocks (via a processor) and what will be accomplished by hardware devices. Here’s an example common to most embedded engineers:
for (i=0; i<10000;)
In this simple program, a multiply-accumulate loop is called 10,000 times while an inverse square root function is rarely used. Add this realization to a basic design heuristic, namely, that the cost of implementing a function in hardware is usually much greater than implementing the same function in software. This means that the multiply accumulate function might best be implemented in hardware, while the inverse square root calculation should be accomplished in software (via a general purpose processor).
Granted, this was a very simple example. Real design projects will be far more complex, including systems with thousands-to-millions of line-of-code and many different kinds of hardware components. System-level constraints will add to the challenge with such important considerations as execution time, total power consumption, memory usage, design footprint and more.
But it’s important to remember the basics. Balancing hardware-software trade-off decisions is seldom an easy task, but the complexity of both the process and the product can be managed as long as designers understand both high and low-level points of view.