06 August 2004
Someone has to do it
Tool chains for software development present a big opportunity. Philip Ling reports.
Designing an integrated circuit would be daunting to most of us. Even chip designers find the challenge is great; so much so that it supports a dedicated sector of the industry – electronics design automation – which, to some, is more complex and intricate than ic design itself.
EDA tools are often massively expensive to develop and superseded relatively quickly, such is the pace of chip design. As a result, it is a sector worth millions of dollars.
But the chip development community is relatively small; multiply its size by, say, 100 and you might approach the number of embedded software developers. And if developing embedded software was as complex as designing a chip, imagine how much interest there would be in supplying the tools.
And this is just what is happening. The complexity of embedded software is growing rapidly, not only because the software is doing more, but it also has more hardware upon which to do it. Highly integrated systems on chips, multiple processor cores, extensible architectures are all with us; the problem (or opportunity) is the software development tools aren’t keeping up.
As an example, ARM recently announced MPCore, a multiple processor solution integrating up to four instantiations of an ARM11 based core on one device. To get the most out of those four cores, the software kernel should be able to assign tasks dynamically (also known as symmetric multiprocessing). That means tasks should be allocated at runtime to the least taxed core at that moment. But ARM admits the software tools needed to enable this aren’t here yet and it could be another two years before dynamic/symmetric multiprocessing becomes mainstream.
Another example is the embedded software design and verification framework introduced this year by Toshiba. It isn’t the framework that’s important here, it’s the fact that Toshiba recognises that providing some form of framework to support highly complex devices is a valuable asset. Engineering teams no longer have the resources to dedicate to non differentiating tasks, such as making sure the debugger can talk to the hardware.
Yet another example is featured on page 33 of this issue, which details a platform developed by Cambridge Consultants to enable the rapid creation of ‘custom’ software development environments. This recognises how important it is to provide the right environment when introducing a new device.
Without such tools, developing the software environment could take longer than developing the device, particularly with today’s accelerated hardware design paths (such as structured asics). But it is still a relatively undeveloped area of the embedded market. Cambridge Consultants has expertise in its field, but it isn’t primarily a software development tool provider. Those third parties which specialise in IDEs build a legacy of supporting a family of processors and do not, as far as we know, use a framework that can be rapidly customised to a new device or architecture.
Adding a little spice to all of this is Eclipse, an open source environment with a growing fan club. It has already been adopted by Wind River and QNX; more recently, Altera used it for its IDE supporting Nios II, the second generation of its embedded processor. Based on – and largely supporting – Java, Eclipse is moving closer to the embedded world as there is currently an Eclipse project underway to develop an open source C/C++ development environment.
The open source community had always been a lurking threat to commercial software vendors; Linux, for instance, is now often found in low cost consumer items. But it has always been a threat without an epicentre – it couldn’t be beaten because it couldn’t be contained. It had a ‘vive la resistance’ feel about it, carried along by a band of happy developers willing to dedicate their own time to the greater good.
But with Eclipse, that band has taken an interesting turn; its disparagers have become its proponents.
This material is protected by Findlay Media copyright
One-off usage is permitted but bulk copying is not.
For multiple copies contact the