Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Hardware/software co-dev't with emphasis on software

Posted: 06 Feb 2012 ?? ?Print Version ?Bookmark and Share

Keywords:EDA? hardware adaptation layer? IDE?

Though I have been in the embedded business for a good few years now, 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 quite 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.

#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?

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.

However, 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.

#2: Integrate with my favorite IDE
Programmable devices offer fantastic opportunities for innovation but, all too often, the tools required to design the hardware disrupt normal software development practices. Engineers are coerced into using tools that are simplistic, lack features, and do not mesh well with existing flows.

1???2???3?Next Page?Last Page

Article Comments - Hardware/software co-dev't with emph...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top