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: Will software have an impact on the cost of developing chips at future process nodes?
Roane: The really interesting thing about software development is it’s not tied to a geometry. The geometries enable chips to pack more, so that results in more complexity. The number of ASICs is dropping, but the number of chips going into production continues to rise. Therefore, the amount of software—if you look at line count and the amount of memory consumed—is escalating.
McLellan: At 65 nanometers, there are almost no products other than cell phones that have enough volume to warrant putting a true ASIC into production. Increasingly, the semiconductor companies are dropping out of the race to develop their own chips because it’s so expensive and aligning with TSMC, Crolles and UMC. Once you can’t differentiate yourself with silicon, you move to software. Even companies that think of themselves as semiconductor companies now hire more software engineers than hardware engineers.
Q: So basically the cost is going up, and so is the amount of software?
Kleidermacher: This is following Parkinson’s Law, which says the use of a resource will expand to consume that resource. It doesn’t matter if you throw more cores at it or bigger caches. We’re going to write more software to fill the resource. If you asked us this question five years ago, we would have said software is getting more complex. What’s different is we’re getting to an inflection point. In 1990, the average car had 1 million lines of code. It seems like a lot, but 1 million lines of code is actually pretty manageable. In 2010, the General Motors CTO predicts that the average car will have 100 million lines of code. We’re getting to a point where the complexity is so enormous you can’t manage it with traditional methods. You have to attack it in a different way.
McLellan: There are two things going on. At the low end, microprocessors can’t get any faster without having reasonable power dissipation characteristics. That’s forcing the move to multicore, which in itself is a big inflection point. Designing software, debugging it and getting it right for multicore systems is very difficult. And at the high end, things are getting far more complicated. The 100 million lines of code in a car is going to run on a hardware infrastructure networked around the car with 100 processors. We have one customer, Ericsson, which uses our software for 3G base-stations. A fully configured 3G base-station has 66 boards in it and 700 processors.
Roane: What’s interesting about all of this is that it touches our own everyday experiences. For the (Toyota) Prius, 70 percent of the development costs are for electromechanical switches. These are embedded systems that control everything from the fuel mix to how much power is coming from the gasoline engine and the electric motor.
Serughetti: The problem is amplified because these are not standard devices. You have to consider not only the silicon on the chip, but the base-station around it and how you bring those things together. The system is growing.
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 percent.
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.
Click here for more information
