Whose job is it, anyway?

Whose job is it, anyway?

The inspiration for this week’s blog entry comes from a comment left by Jason Andrews from Cadence. Jason is an all around good guy who has been working this area of hardware and software for quite a few years, too. Here’s a link to his blog over in Cadence-land – Jason Andrew’s Blog.

Anyway, Jason pointed out that the EDA companies need to get with the program and realize that software is a part of the product that their customers deliver. And he’s right. (Although, if you listen to what Aart, Wally, and the executives from Cadence are saying, there is some recognition of a problem here.) But, it’s not just the EDA companies that need to make this connection. There are folks in the design community who need to wake up to this reality, too.

Since I work with both hardware and software folks, I keep up with what’s going on in both worlds. I try to go to the big conferences for both hardware and software developers. On the hardware side this is the Design Automation Conference (DAC) and DVCon. On the software it is the Embedded Systems Conferences (ESC).

Recently at DAC, I was talking with a hardware developer. I was explaining to him the benefits of Seamless, one of the products that I work on. One of the key value points for Seamless is that it ensures that the hardware/software integration time will be minimized. Essentially, it allows the software developer to exercise their code against the hardware before it is built. This averts lots of nasty surprises when the software guys get their hands on a prototype.

The hardware developer, we’ll call him Mr. H, was unimpressed. He kinda shrugged. I was curious about this reaction, so I asked him what he thought. He said that it wasn’t really his job to make sure that software could run on the hardware. If the software guys can’t get things to run, that’s really their issue – not his. But he thought that the software team should really see a demo of Seamless, since they really do have a lot of trouble getting things running once they get their hands on a prototype board. He thought something like Seamless would really help them out.

This reminded me of a conversation I had at ESC last Spring. I was explaining how Seamless works to a software developer; we’ll call him Mr. S. Mr. S nodded a lot and thought it was a pretty good tool. But, he didn’t think he could use it. He never gets access to the hardware design early on. Even if he did, he wouldn’t know what to do with it.

“You should really show this to our hardware team,” he told me enthusiastically. “We take a long time to get hardware and software integrated, usually because of problems in the hardware. If they could use something like Seamless, I think it would help them a lot.” He explained to me that it wasn’t his job to make sure that the hardware was built right. “If they screw up the hardware design, it makes the project late – but there’s not much I can do about that.”

Both Mr. S and Mr. H are right, of course. They have been hired to perform a specific task in the development of an embedded system. It’s enough for most of us to accomplish the tasks we’ve been assigned by our employer – let alone take on other person’s work, even if that work has not been assigned to anyone. While it’s nice (for his employer) that Mr. H worries about the software guys, it’s also nice that Mr. S worries about the hardware development. However, until management makes it a requirement – part of their jobs – integrating hardware and software will be an afterthought in the design process.

The real problem is that if neither Mr. S nor Mr. H take on the task of getting hardware and software to work together, it doesn’t get done…and then it gets left to the end of the project. We’ve all seen the studies that show how the costs to fix problems increase exponentially as they are found later in the design cycle.

There are a lot of folks in the industry that have seen a problem here. But, 75 to 80 percent of all embedded systems are delivered late; and almost half do not meet their performance goals (according to a 2009 survey done by Embedded Market Forecasters). These numbers have not budged in the last decade that I’ve been reading this survey. If you want to start improving the outcome of these projects, one of the areas that you’ll need to look at is getting hardware and software integrated earlier.

More Blog Posts