HW/SW co-development (with finally some emphasis on software)

I’ve been in the embedded business for a good few years now, and I still cannot figure out whether “co-development” refers to a manager’s dream of hyper-efficient project scheduling or an instrument of torture for software developers. It probably just means that software is developed in parallel with the hardware platform design but if this isn’t a synonym for torture, I’m not sure what is.

In the embedded world, it is very common to write software for a board or chip that is simultaneously in the process of being designed. Sometimes the target is a complex ASIC design in simulation environments from EDA vendors like Mentor Graphics or Cadence Design Systems.

Sometimes it is for powerful FPGA designs, from companies like Xilinx or Altera, with embedded microprocessor cores interfacing to standards-based and custom IP blocks.

And sometimes it is for programmable systems-on-chip, that integrate programmable digital and analog functionality with microcontroller, like the PSoC devices. These are all powerful environments that enable fabulous innovation and have one torture-inducing feature in common; the hardware can change at a moment’s notice and the software developer will have to react.

I’m not suggesting we slow down the pace of innovation just to give software engineers a breather. Quite the reverse, actually. Hardware tools need to be better integrated with software IDEs in order to accelerate time-to-market. Designers need more tools and methodologies that isolate the application from hardware changes. I’m not talking about major communication blocks being added or removed from the design.

If that’s your problem, your software engineers should probably be working on something else because your hardware design is no where near ready for them! I am talking about minor changes to defined functional blocks occurring late in the design cycle, things like register addresses that move, bit meanings that get re-defined, buffers that change size, and so on. All of these “minor” edits cause ripple down into the software that can result in product defects and substantially re-work long after the reason for the hardware change is forgotten.

Software Engineers! It is time we stopped letting the tail wag the dog. Here are three ideas to change how we develop applications for moving targets. Don’t embark on your next project without them!

Idea #1: Don’t Write the HAL. Generate it!
The first change we need is for the hardware development tool to generate a software interface, often called a hardware adaptation layer (HAL). The HAL should include boot code that reliably initializes the programmable hardware and provide APIs to enable software control of the system. More than just simplifying firmware development, the HAL abstracts away the implementation from the interface. This means that small changes to the hardware can be implemented without perturbing the firmware.

There is nothing new in the idea of a HAL and many experienced designers have written intelligently about the need for consistent, intuitive naming conventions for constants, functions and variables. But, for programmable devices like FPGAs, CPLDs and PSoC, I would extend those requirements to include the need for the HAL to be generated by the hardware design tool itself. How else can the software engineers be guaranteed a reliable interface?

Figure 1: A snapshot of a PSoC Creator workspace showing the API files (HAL) for a system controller design using a FanController block and a pair of Comparators (Comp_Hi and Comp_Lo).
In a static or slowly-moving environment, such as a fixed-function MCU or large-scale ASIC project, it is reasonable to consider the HAL to be an independent suite of APIs and to modify it as part of a hardware design change.

But with modern programmable devices the hardware can change multiple times a day. Manual HAL maintenance is simply incompatible with this methodology and would guarantee errors in the implementation, not to mention a good deal of torture for the software engineers! In my opinion, automated HAL generation should be a must-have requirement for any programmable platform.