Keep The Silos

By Jon McDonald
I’ve had a couple of conversations recently in which software developers expressed that they have little interest in working with hardware or systems developers. The general sentiment seemed to be “when [a place commonly regarded as extremely hot] freezes over” they might consider it. Perhaps for those living in northern climates there may be a possibility of this freeze, but I won’t hold my breath.

Initially, this sentiment appeared to be somewhat harsh and maybe even misguided. After all, massive interdependence between hardware and software determine the success or failure of many products today. SoCs are getting so large and the NRE cost is such that first pass success is often required to have a competitive project. Given the scale of the consolidation of hardware and software onto an SoC, I felt there should be a similar level of integration between the hardware and software developers. This felt right to me as a hardware developer, but it did not appear to feel right to the software developers.

After a little more reflection, I realized that the software developers and the hardware developers cannot be forced to work together. And, while the success of their products may be heavily influenced by the hardware and software working well together, the hardware and software engineers don’t necessarily have to work well together.

They really are working independently. Software developers don’t need to know that much about the details of the hardware design. They don’t need to know the intricacies and tradeoffs in the bus structure or the memory subsystem latency. But they do need to understand the impact of the way they write their software on the performance of the overall system, and they do need to understand if they are using the system as efficiently as possible.

It’s like driving a race car: I don’t need to know exactly how the engine functions, or how the steering connects to the wheels, but I do need to understand the power and performance capabilities delivered by these elements and use them effectively to achieve the best race results.

On the other side, hardware developers need the software to be able to understand and optimize the system for the true workload it will be facing . They don’t necessarily need to understand the software, but they do need to understand how the software uses the hardware, what kinds of utilization will be achieved, and where bottlenecks might exist in the system as it performs its intended function.

I believe the truth of the matter is that the hardware and software engineers do not need to work together directly, which is probably a good thing because often they don’t want to work together. Still, they each need to work in a context that makes the implications and decisions made by either side obvious to the other. Ultimately this is one of the tremendous values delivered by system-level design. The hardware community can create a virtual model of the system that is used by the software developers. Just like the racecar driver learns how to most efficiently drive the car by the very act of driving it, the software developer can learn how to most efficiently use the hardware through programming it, and the hardware developer can analyze the performance of the hardware under software load to optimize and tune the hardware.

In the end, I believe we will achieve tight integration of the hardware and software communities not by forcing the engineers to work together, but by linking their work through a virtual platform that benefits both communities without disrupting their development processes.

—Jon McDonald is a technical marketing engineer for the design and creation business at Mentor Graphics.