Not long ago embedded software engineers worked in isolation, with no standards, no common platforms, nothing reusable for future projects, and no collaboration with any other company. A collaborative ecosystem is starting to break through that isolation and greatly improve software productivity - and it needs your support, according to panelists at the recent ARM TechCon conference.
The panel was titled "The Future of Collaborative Embedded SW Development, From the Viewpoint of One Technology Chain Gang." No, nobody is breaking up rocks under the watchful eye of a deputy sheriff. The term "technology chain gang" comes from the realization that modern embedded software development requires components from a "technology chain" of collaborating companies, including processor, platform, operating system (OS), semiconductor intellectual property (IP), and tool providers.
As shown from left to right in the photo below, the panel included these participants:
- Larry Lapides, vice president of sales, Imperas Software
- Victoria Mitchell, director, embedded software, Altera
- Jim Ready, chief technology advisor, Cadence
- John Goodacre, multicore evangelist, ARM
- Mike Demler, senior analyst, The Linley Group (moderator, at podium)
Following are some excerpts from the panel discussion.
Q: Where is the ecosystem today for embedded software development?
Lapides: I think the community is sort of just getting by, just getting chips and boards and systems into the market and praying they will work. I don't see a software development and test methodology keeping pace with the way hardware is evolving.
Mitchell: I think in recent years we've made some progress, particularly in the ARM environment with embedded Linux. We still have some challenges ahead of us. I think standards in interfaces are super important, but we also don't want to forget about opportunities to differentiate.
Ready: When semiconductor guys try to differentiate their products through hardware, you get a natural proliferation of interfaces and a customization of Linux. That's so the vendors can go to market. The structure of the industry does lead to a lot of chaos and churn, and a lot of duplicated effort in the supply chain.
Goodacre: We're at a stage now where few companies are making money selling just software. Most software experts are in the hardware companies. There is no longer value in just creating software - the value is what you can do with it.
Q: Jim, does Cadence provide tools that will help with software development?
Ready: Cadence is primarily an EDA company. My job is to understand whether there is an opportunity for an EDA company to help with software. I think the single biggest thing we can do is to provide a place where the software guys can execute software before there's a chip, and execute on the best possible model of the SoC [system on chip] under development, such as an RTL model of the processor.
The problem is that trying to do that with Android is an enormous challenge. It's a huge amount of software and it takes a long time to execute, even in emulation. There's a lot of effort on bridging that gap.
Mitchell: It's really important to enable the software team early on with something that keeps them productive. It's also critical to come out with the highest quality software.
Q: John, what is your view of embedded software and the collaborative ecosystem?
Goodacre: I group software into three aspects. First, you have enablement software, which is non-differentiating software you need to get something going. Companies need to work together across the ecosystem to do that, and Linaro is a great example. Another class of the software is the tooling, including APIs and EDA. A third class is the software that enables the value proposition of the device. That's differentiating software you really want to focus on, but it really isn't valuable apart from the device.
Q: Is Google, with Android, part of a collaborative ecosystem for embedded applications?
Ready: Google defines what Android is. Any particular revision of Android may be targeted at some reference SoC, which leaves everybody else having to move up to that particular revision. If you have an SoC with a subsystem that does some neat things, perhaps some imaging, there may or may not be an interface in Android or a hardware abstraction. What you end up doing is ripping out a software subsystem, if there is one, and redesigning.
Q: How will QEMU and OpenCL impact embedded software development?
Lapides:QEMU has had a significant impact -- it has already been part of Android development kits. The problem with QEMU is that it is open source, unsupported, has GPL licensing, and is not a complete model of an ARM processor.
Mitchell: We think there is a strong benefit for QEMU - if you develop something in Android you can get down there and touch simulators. The challenge is that it's difficult to support a changeable platform, such as an SoC FPGA. That's where we see OpenCL coming in.
Goodacre: OpenCL is an assembler language for saying "I don't really care when you do it, but please do these things as fast as you can." But you have to say "I've got 256 of them" if you have 256 lanes in your architecture. To really take off like C code did, OpenCL is going to have to be more micro-architecturally abstract.
Q: How are we going to get to a better collaborative environment in the future?
Lapides: The high cost of silicon respins forced a significant collaboration between tool vendors, IP vendors, and customers. The software industry is different because there is no one big cost. But costs are adding up to the point where something has got to be done.
Mitchell: Things are actually getting better. Embedded software used to be all mine, all closed, and everything we're doing is to launch a single product. Now we're opening up a bit and trying to follow the PC model where there was a much more collaborative environment and a standard platform.
Ready: The best way to make software engineers more productive is to have them not write software in the first place. That's what happened with Linux in embedded systems - it was 50 million lines of source code you didn't have to write. Collaboration on common things, as brought forth via open source, is the source of productivity in software engineering.
Goodacre: We're not where we were 20 years ago. We're not just building one device that does one set of platform functions - we want to have devices all over the place. To do that we need to have a collaborative effort for enablement software. It's not differentiating and you're not going to make any money on it. So everybody has got to help with the platform. To use it effectively, please pay for the tools.
Richard Goering
Related Blog Post:
Software-Driven SoC Development - The Next Big Step in IC Design?