I’ve spent the last 20 years of my career working in that nebulous space between the hardware and software worlds. That’s why I’ve chosen the title of this blog to be “It’s all about the software.” It’s a phrase that Steve Jobs used when describing the Apple iPhone. While the hardware of the iPhone is fantastic, and the industrial design is unparalleled – it is the software that makes this embedded system a category-defining and market-changing product. While Mentor Graphics is a company that makes its bread and butter building hardware design tools, I think it’s critically important for us to remember that our customer’s job isn’t done until there is software up and running on the hardware that they build. I think Jack Ganssle put it best when he said “Hardware, without software, makes a nice doorstop,” (although my iPod, with or without software, could barely pull duty as a paperweight.)
In this blog I’ll be musing on subjects where hardware and software intersect. I find it an amazingly interesting, but often overlooked subject. Hardware development is a well-defined engineering process, and software development is, too. But, bringing hardware and software together is a bit of a black art. This is partly because hardware and software folks tend to think in such different terms. I believe that it’s also due to the way that embedded companies organize themselves. There are clear distinctions and boundaries set up between the hardware development teams and the software development teams. I’m amazed at how often they are in different buildings, cities, countries, and even continents.
Imagine setting up a hardware development team (or a software team) in such a way as to ensure failure. How would you do it? One good way would be to put half the team in Munich and the other half in Chicago (or any distant pair of cities with different languages, time zones, and national sports). Next, don’t let them talk to each other very frequently. Use paper specifications to convey information from one half of the team to the other. Paper specs always contain mistakes and get out of date quickly – no one reads them anyway. And no one ever updates them as the project changes. Don’t let them ever bring the two halves of the project together for any kind of a checkpoint – wait until the very end of the project to do the integration. And when the integration does occur, make sure that the teams are using incompatible debug tools – so no one can see what’s happening on both sides of the system at the same time. This will ensure that the integration period lasts as long as possible. Would it surprise you if this type of team failed? Yet this is exactly the way that hardware and software teams are often organized. Believe me, I was on the phone with just such a team this morning. If this resembles your organization, don’t worry – you’ve got lots of company. What’s most amazing to me is when the managers of these teams are surprised and shocked that the hardware and software don’t come together smoothly at the end of the project. They should be shocked when things do come together.
Ten years ago I made a (too public) prediction that in a decade, in the embedded space there would not be “hardware engineers” and “software engineers” – but there would be only “embedded engineers” competent in both domains. I sure got that one wrong. I made the prediction because I was watching embedded systems get more complicated, with more functionality being put in software and the interactions between hardware and software increasing. I was seeing companies make very expensive mistakes. It seemed clear to me that companies would want to avoid those mistakes in the future. But, I think the situation has gotten worse over the past ten years, not better. Despite increasing software content in most embedded systems and increasing interaction between hardware and software, most companies continue to do things the old-fashioned way.
And things are only getting worse – Multi-core or Many-core, whatever you want to call it – is undoubtedly going to change the nature of processor system development and programming. It’s going to be really interesting to see how this will impact hardware and software designers in the embedded space. It’s hard enough to get hardware and software to play together nicely when there is one processor. What will happen when there are 20? Or even 200?
We live in interesting times.