Our sister websites in the US Electronic
News/Electronic Business sat down to discuss the future of
software development with Dave Kleidermacher, CTO at Greenhills
Software; Paul McLellan, v-p of marketing at Virtutech; Marc
Serughetti, director of marketing at CoWare; Jeff Roane, v-p of
marketing at VaST. What follows are excerpts of that
conversation.
Q: The electronics industry has begun shifting
many of the hardware design problems into software. What are the
issues that are starting to crop up in software development?
Kleidermacher: For some customers it’s
reliability. For others it’s time to production. The challenges
vary widely from one customer to another. The solution they need
will vary, as well. It may be tools, operating systems,
consulting.
McLellan: There are a lot of issues, but whatever
your issue is, it’s getting worse. The software component is
becoming a bigger component of electronic systems. It’s even in
things you never thought of as electronic systems, like planes and
cars. Issues like time-to-market and quality are exacerbated by the
fact that we don’t an increase in the number of software engineers
to write this stuff.
Roane: The problems we deal with are more.
Customers have more complexity, but the added component is
complexity through obfuscation. As a result of trying to develop
software for embedded silicon systems, the view into that software
is obfuscated. If you’re developing software on a PC, you can do
that with great visibility and control. If you’re developing
software for a silicon embedded system that has multiple cores,
your visibility is impaired.
Serughetti: One of the big issues we see is
hardware availability. The hardware might not be available because
it’s still in development. Or it’s so complex that having it in
place, like a large networking system, is very difficult or not
readily available.
Q: Convergence and integration have been
particularly pronounced on the hardware side. Is that same trend
occurring in software?
Roane: The software determines how many resources
are bought and consuming power and power dissipation. It’s a
user-visible capability. It’s something companies use to
differentiate their device. Over Christmas, Samsung introduced the
BlackJack (smartphone). It comes with two batteries.
Q: That’s always a bad sign.
Roane: Yes. And if you go on the Web, there’s a
long trail of discussion about the power consumption, which is why
they began shipping an extra battery. It’s a software and hardware
problem combined.
Kleidermacher: The weapons that you need in your
arsenal are going to vary from customer to customer. We have a
customer that’s building a handheld device that’s also an MP3
player. We have a tool that helps you find bugs, but they used it
to analyze the cache. They did a quick rearrangement of the code
and they reduced their power consumption by 15 per cent.
Serughetti: The problem is that software
performance is an afterthought. It’s not being done early enough in
the design. What you have to do is rework the software because your
software is consuming too much power. We see a need to change the
way software has traditionally been developed, which is to wait for
the hardware. That’s where simulation technology becomes really
interesting. Simulation has been used for a very long time in other
industries. Software is the only sector that is reluctant to
approach this.
Roane: It’s partly that they’ve never done this,
but part of it is also that these new methods are borne out of
technology. There is new technology that allows you to do software
development ahead of the actual devices.
Q: Does all of this get more complicated with
the increasing number of cores within processors?
McLellan: The software doesn’t know in advance
whether its going to be running on 2 cores or 16 cores. That is
still a research problem. What’s happened is that semiconductor
companies realized they had a power problem and that they could
only deliver multicore chips—and the software people will be able
to cope with that. Container trucks work because they’re all the
same size. This is like saying they’re going to give us an
unlimited number of Federal Express vans. That doesn’t work so
efficiently because they’re all different sizes. Serughetti: It’s
how you balance your performance, flexibility, power—all those
different aspects. But in multicore, you also need the
programming.
Q: Isn’t the problem with multicore processing
the number of ad-hoc queries?
McLellan: If you’re using a desktop machine and
you’re not running something like PhotoShop, which is
embarrassingly parallel, then it’s difficult to see how you can use
these cores. If the granularity of what you’re trying to
parallelize is too small, the overhead kills you, and if the
granularity is too big, you’ve got all these processors sitting
idle. To some extent, everyone has been designing quality at the
back end. We need to design it at the front end.
Roane: There are two clear problems. One is a
programming problem. The tools that allow you to partition your
software need to mature. On the other side, there’s simulation
technology. If you’re considering whether a four-core system is
better than a two core system, you can pull that together
relatively quickly. Assuming you can solve the programming problem,
you can get some hard data about how that runs.
Kleidermacher: Multicore is a big trend and there
are a lot of designs going that way. We’ve been looking at it from
several different angles. One is how you develop the application on
multicore. The second is, how do you debug an analyze that, and
what are the interactions? The third is, what does the run-time
environment look like to best manage the software? In terms of how
you develop, we believe this whole parallel/concurrency issue is
overblown. Most applications in the embedded space are already
multithreaded. The issue for us is not whether my system is going
to take advantage of multicore, but whether there’s a standardized
way of doing multithreading. In debugging, there’s virtualization
that can help you. One of the new trends is multicore trace. ARM
and Nexus allow you to trace not just one core but multiple cores,
and not just the CPUs, but accelerators and other kinds of engines
on that system. You might have four or five different things going
on at the hardware level. If you can trace them all together in a
time-correlated manner, you have amazing visibility. And at the
run-time level, if you’re running an SMP operating system on that,
you’re done.
Q: But you’re talking about a very limited
portion of the market. This is not an eight-core general purpose
processor, is it?
Kleidermacher: No, you’re absolutely right. The
world of multicore architectures is diverse. There are tightly
coupled versus loosely coupled. There is homogeneous versus
heterogeneous. DaVinci or Cell are tightly coupled but
heterogeneous. That’s a lot harder because there is no standard.
How you talk from an PowerPC to these Cell engines is completely
different from an XScale to a network processor engine, which is
completely different from how a DaVinci/ARM core talks to a DSP
engine. Unfortunately, our life is really bad. We have to make sure
we talk to all their APIs. But the debugging tools can be
common.
McLellan: I don’t think you try to accelerate
Word. But you may try with a game. To get that to work on Cell, you
almost have to hand craft the algorithm down at a very low level.
You can’t take an algorithm written at a very high level and say
there’s a PowerPC in there and eight other processors and make them
all run really fast. You have to figure out what you’re going to do
on each processor and how they’re going to communicate.
Serughetti: That’s a traditional tradeoff between
hardware and software. With software, you get flexibility. With
hardware you gain performance. There’s still a lot of discussion in
the market. Where would you go for a hardware multicore solution?
There’s a lot of research out there with tasks distributed around
each core. On the other side, you have software solutions.
Different applications will drive different needs.
McLellan: There’s another trend that is starting
to happen. The U.S. is a laggard in this, but it’s about thinking
of systems more holistically. Before the Boeing 787, each of their
subcontractors had to supply a piece of hardware that was networked
together, and within that hardware ran the software. There were a
lot of wire harnesses and a lot of weight. The 787 is more
integrated at the software level.