This is the third in a series of newsletters that present seven principles to help guide your own processes and best practices in hardware/firmware interface design. This month’s principle focuses on balancing the tasks and workload between hardware and firmware.

Hardware and firmware each have their strengths and weaknesses when it comes to performing tasks. The challenge is to achieve the right balance between the two. What applies in one embedded system will not necessarily apply in another. Differences exist in CPU performance, bus architectures, clock speeds, memory, firmware load, and other parameters.

Proper balance between hardware and firmware depends on the given product and constraints. It requires studying what the tradeoffs will be for a given situation and adjusting as necessary.

An embedded system without a proper balance between hardware and firmware may have bottlenecks, performance issues, and stability problems. If firmware has too much work, it might be slow responding to hardware and/or it might not be able to keep hardware busy. Alternatively, hardware might have too big of a load, processing and moving data excessively, which may impact its ability to keep up with firmware requests. The quality of the system is also impacted by improper load balancing. The side with the heavier load may be forced to take shortcuts, fall behind, or lose some work.

A simple example to illustrate this point is to calculate the parity of a byte, a task often required in communication and storage applications. A firmware routine has to use a for() loop to look at each bit in the byte to calculate its parity. The following listing is an example in C of a for() loop to calculate parity by exclusive-ORing each bit.

// Generate the parity of a byte
char generate_parity (char byte);
  {
  char parity; // Contains the current parity value
  char bit; // Contains the bit being looked at
  char pos; // Bit position in the byte
  parity = 0;
  for (pos=0; pos<8; pos++) // For each bit in the byte
    {
    bit = byte >> pos; // Shift bit into position
    bit &= 0x1; // Mask out the rest of the byte
    parity ^= bit; // Exclusive OR with parity
    }
  return (parity);
  }

The four-step for() loop translates into several assembly language steps that must be repeated eight times requiring multiple CPU cycles to do so. Other algorithms exist with various impacts on time and memory, but none can get close to the performance that can be achieved using a hardware implementation. This next listing of Verilog code illustrates how hardware can exclusive-OR all eight bits together in a single clock cycle.

module parity(
  Data,
  Parity
);
input [7:0] Data;
output Parity;
assign Parity = Data[0]^Data[1]^Data[2]^Data[3]^
                Data[4]^Data[5]^Data[6]^Data[7];
endmodule

Like the firmware version, the hardware version has several steps (levels of logic) to it. But since it can access all eight bits at once, the parity is generated in a single clock cycle. In fact, the parity can be generated while the byte is being transferred on the bus.

Another example is the tradeoff for calculating floating-point numbers. It is faster to calculate them in hardware with a floating-point coprocessor, but it adds to the material costs of the product. Performing the calculations in firmware is slower but reduces parts costs.

The lesson here is to consider the tradeoffs between the hardware and firmware tasks and to determine whether the balance needs adjusting. Do the I/O buffers need to be expanded? Do interrupt priorities need to be adjusted? Are there firmware tasks that could be performed faster in hardware? Are there hardware tasks that require the flexibility of firmware? Are there handshaking protocols between hardware and firmware that could be better tuned? Are there ways to reduce material costs by having firmware do more?

Balancing the load between hardware and firmware requires collaboration between the hardware and firmware engineers. Engineers understand the load impact associated with a task in their own domain but may not fully realize how it impacts the other.

A principle of economics applies here—two parties will be more productive if they work together, but with each working on the tasks that suit them best.

• Principle 3: Balance the Load.

Until my next well-balanced newsletter…