It has always seemed obvious to me that a particular characteristic, that makes embedded software different from desktop programming, is the close relationship with hardware. As most embedded devices are custom designs, the hardware platform is something of an unknown. So, it is clear that the development of the hardware and software should be done in a cooperative fashion.

Traditionally, there has been something of an “us and them” situation between hardware and software teams. Matters are improving, but I have noticed some subtle nuances that influence their relationship:

Software cannot wait for hardware. Historically, the software development would begin when stable hardware was available. Nowadays, with longer development cycles and shorter times to market, work needs to begin much sooner. This means that software developers need access to the hardware designs, which leads us to the next challenge.

Software and hardware developers do not use the same tools. Expecting either party to change is not really reasonable. As an executive in the EDA industry recently put it: "Asking a software designer to use a hardware design tool is like asking a plumber to install your sink with an electrician's wire cutters." I sometimes give a talk on real-time operating system performance measurement and suggest that an oscilloscope might be a good tool to look at time delays. Software engineers are somewhat nervous about using such an instrument.

The cost models are different. I recall an EDA sales guy saying that he could not understand our price list: "So this debugger is a sophisticated tool, critical to software development, but it only costs $5K? Why can you not charge $50K?" When I explained that many software developers expected to get tools for free, he was speechless.

Power changes everything. Historically, the hardware was designed and built and handed over to the software team, without any prior consultation – except maybe CPU selection may have been discussed. Because nowadays software design starts first, the developers are often in a position to provide guidance – define the resources that they need instead of just using what they are given. As power management becomes a critical design requirement, software directing hardware design is becoming the norm.

We have come a long way from the days when a single engineer designed the hardware of an embedded system and then implemented the (simple) software as an afterthought. Software engineering is now usually the biggest part of the overall development effort. As hardware is designed using tools that look suspiciously like programming languages, who knows what the development teams of the future will look like?