Hardware-Software partitioning

Embedded Systems have reached such a complexity that it has become impossible to design them “from scratch”.

That above statement [Seminar “Embedded Systems”, Hardware/Software Partitioning, Frederick Dufour – 2006, July 3rd] is maybe the proverbial bridge too far. Since every problem can be decomposed into smaller problems, it IS possible to design a system from scratch. The question is whether this is economically viable. Also, it costs time to reinvent the wheel. Lots of time. So, it makes sense to look around and shop for building blocks one can use. Mechanics, analog and digital ICs, FPGAs, microcontollers and firmware and/or software can be combined in several ways to become a solution, which is possibly a combination of embedded device(s) and services (i.e. applications that connect embedded devices to centralized data and services). Each combination has its advantages and disadvantages with regard to material costs, speed of development and attained processing power.

Partitioning is used to define boundaries between tasks which can be implemented in hardware or software. Somewhere, there is an optimal combination of hardware and software: The optimal combination for processing, or costs, or time to market. It all depends where the priorities lie. There are several algorithms that try to solve this optimization problem. Simulated annealing – for example – could be used to try to detect (optimal) sweet spots in the solution space. But the discussion of these algorithms is an academic one. In reality, embedded system composition seems more like a black art the system designer should possess.

Cost-effective designs should use a mixture of hardware and software to accomplish their goals.

You can put everything in hardware, but that path is rarely chosen because of cost, lack of flexibility and time reasons. However, it is impossible to put everything in software for an embedded device. All Android apps could (but we choose not to do so) also be categorized as embedded software, and so the Android device is the medium your ‘solution’ or service runs on. In that case, it is also a given property, and it is not under the control or influence of the ’embedded software’ designer. Hence, one has to live with it and adapt what can be accomplished. But what if you CAN shift processing assignments to and from software and hardware?

As defined by Gupta and De Micheli, [R. K. Gupta and G. De Micheli. Hardware-software cosynthesis for digital systems. IEEE Design and Test of Computers (Sept. 1993), pp. 29–41., 1993. ]
“The system-level partitioning problem refers to the assignment of operations to hardware or software. Overall system performance is determined by the effect of hardware-software partition on utilization of the processor and the bandwidth of the bus between the processor and application-specific hardware. Thus a partitioning scheme must attempt to capture and make use of its effect on system performance in making trade-offs between hardware and software implementations of an operation.”

Right. But nowadays, modern micro-controllers already have lots of hardware and integrated peripherals to offload the main processing core. Memory transfers, cryptographic calculations, graphic data manipulations and so on… are – depending on the spec of the micro-controller – no longer handled by the main processing unit. The boundary between DSP and general purpose controller is fading. The transition from 8 and 16-bit to 32-bit high-volume embedded systems is accelerating, FPGAs are getting cheaper.

How do you go about partitioning between hardware and software in a practical way?

• Determine the anticipated volume of the target device: The cost optimization possibility for high volume devices almost always lies in manufacturing and less in ease of development.
• Determine the required processing performance and bandwidth demands. Make realistic (and pessimistic worst-case) estimations and calculations.
• Is it feasible for a more general purpose processor, then use that for prototyping and simulations first. Later, one can downgrade the processor or controller, and add hardware components to offload the general purpose unit.
• Select a controller family where you can easily upgrade and downgrade in performance and cost.
• In case of massively parallel processing, FPGA comes in the picture: FPGAs can provide 50 to 100 times the performance per watt of power consumed than a microprocessor. Algorithm suitability (1), floating point vs. fixed point number representation (2), and general difficulties associated with developing FPGA software (3) determine the utility of FPGAs for a particular application. (cfr. http://www.rtcmagazine.com/articles/view/102015)
• Software is supposed to be flexible while hardware development is considered to be more rigid.
• Apply black magic ‘system designer’ dust 🙂

Somebody has already selected the ‘platform’ to be used, what now?

• Determine the anticipated volume of the target device.
• Determine the required processing performance and bandwidth demands. Make realistic (and pessimistic worst-case) estimations and calculations.

If it fits the selected platform, fine. If it does not, or if you have a better candidate (and you can back it up with objective data!), then tell management first (and possibly the client later) in a firm but diplomatic manner. If they still want to go ahead with – what you consider to be – the inferior selection, you are expected to make the most of it. But at least, a warning was raised that can save your head later on.