News and New Products

Refining multicore concepts

By Ann Steffora Mutschler, Senior Editor -- Electronic News, 6/22/2007

Simon Davidmann, CEO of Imperas, David Stewart, CEO of Critical Blue, EDA industry analyst Gary Smith, Ian Mackintosh, president of OCP/IP and Chris Lennard, director of strategic marketing for the system design division at ARM sat down with Electronic News/Electronic Business during the Design Automation Conference held earlier this month in San Diego to discuss multicore issues. What follows are excerpts of that conversation. This is the first of two parts.

Q: Given the amount of activity in the industry, what does the term ‘multicore’ mean today?
Davidmann: Having worked this for a while, if I look at the trend because of power, and performance and Moore’s law, processors are running out of speed and steam because of power, and yes, there are gigahertz processors embedded and 3 or 4 gigahertz on the desktop, but we need much more software to run, so people are going to concurrent and to parallelism. We see several branches to this multicore tree and this new terminology and taxonomy needed in the multicore space has to be separated between the desktop multicore challenges -- where there is an OS and applications where you don’t have a lot of hard, real-time deadlines – and embedded solutions where you are trying to replace hardware with a programmable solution where everything is about very detailed timing. The architectures are very different and you have to look at the different branches differently. What’s needed for the desktop and multicore and general-purpose applications is very different from what you need to do in an embedded system where you’ve got a lot of hard, real-time stuff where you are replacing hardware with multiple processors and you’ve got dedicated accelerators and coprocessors in there. Multicore is definitely a challenge. There are very different challenges for standard parts and ASIC replacements which is what embedded MP SoCs are. They have different requirements, different challenges -- they both need different ways of programming. One of the big differences I see is that if you are programming on a desktop in Linux and you’ve got a four-core processor, there are millions of people are doing that and you would expect the tools to come from the chip providers or the platform providers. When it comes to an MP SoC, you actually still need the tools, and the challenge is that there are 8,000 of these SoCs being designed a year, according to current estimates, and every single one of those needs a whole software development environment for it, and that is one of the biggest challenges we face. How are you going to program these devices?
Lennard: There are only two points that I would counter on. One, you brought up the concept of “embedded” and you said “real-time.” And I think “embedded” does not imply “real-time.” There’s a large amount of “embedded” that also implies “consumer” and inside of consumer you don’t necessary drive just the real-time but also the concept of application. From the point of view of the concept of application, there is the issue that you need the software development tools that are associated with this. But beyond the concept of bring-up, when you’re not so concerned about the services provided by an operation system, one of the issues associated with software development environments particularly in and around multicore is the intimacy of the relationship between the operating system, its services and how you develop inside those environments. So if you look at the operating systems today that are being provided for multicore, they are provided with tool suites for the development because of that level of intimacy basically between the services and the software programming model. So there is an interesting question in there as to whether or not that whole concept of separability between the intimate OS awareness and the software development environment can be broken out or whether indeed it is the OS providers (like the Microsoft equivalent in the desktop) that are really going to be the guys who are going to drive some of that software development.
Davidmann: The thing I am most concerned about is not the OS bit of it: If one processor doesn’t cut it, and you’ve got lots of jobs running, put two processors down, which is what you are doing with your MP. And that’s a good solution for the general purpose bit of the chip on the side. But actually the challenge I see is that we are going to replace the “sea of gates” with “seas of processors,” and they’re not going to have OSs on them. Distributed OSs don’t exist like that. So a lot of them don’t even share memory between each processor and you don’t have the notion of an operating system. There’s going to be I/O routines in a library but you can’t call that an OS. It’s a very different challenge from the challenge of programming jobs on an OS to actually distributing work over two processors.
Lennard: I think it is relevant to look at it from the point of view of removing the OS or moving to the concept of the microkernel particularly when you are dealing with hard, real-time constraints. When you are dealing with application-based services and so on, people are going to program or want to program to a set of services that they’ve dealt with.
Stewart: The concept of a “sea of processors” is interesting but the way I think about it, it’s the wrong way around. It’s like defining what the architecture is, having a bunch of processors and then thinking about using it. You start with the software you need to process, accelerate, power reduce – whatever you need to do with it – and then you work out what the processing elements need to be to deliver that, as opposed to saying, “Here’s this interesting fabric of all these processors.” It gets back to the old problem of building the hardware and then trying to program it. You develop the software, you develop the tools and those tools tell you what the underlying architectures need to be in terms of how you break it up into different elements because it won’t be a bunch of different processes, it’s going to be different processing engines for different tasks that are all going to be application-specific and scaled in different directions. It will come top-down from the software side. The disconnect is that there are a bunch of different architecture that can’t be programmed. Let’s think about how we do it from the software side, down.
Smith: I look at both multicore and multiprocessing because they fall into the same bucket and we can learn a lot from the guys that have done multiprocessing now that we’re putting it on the core. I separate them into homogeneous and heterogeneous – what Intel and AMD are supposedly doing is homogeneous although what you are seeing is that PCs are becoming heterogeneous because they have graphics processors and very other processors. And Amdahl’s Law basically says, “You’ve got four processors, after that in general-purpose computing, you’re done.” Intel shows this great graphic showing they are going to go up to X-amount of processors, Toshiba had one with 362 processors. There are exceptions and they are called embarrassingly parallel problems. And those are the ones we see in these “sea of processors” and there is no OS, it is basically driven by kernels and a bunch of middleware. All supercomputers are basically multiprocessing engines and they are usually designed for an application – they’re application-specific boxes. IBM’s Deep Blue was built to beat the best chess guy in the world. Other supercomputers are built to test atomic bombs, or do the weather – they know the application first, and then they build the hardware to meet the application. You ask what language they are using and the Mercury guys say, “C of course.” But also have a four million feet deep middleware stack between the C and the actual processing engines. And then there is heterogeneous – and that’s what the cell phone problem is. The problem that we ran into in the semiconductor industry is that the world has been building von Neumann computers for 50 years. The architecture says that it’s a sequential world, and that’s where C came out of. And the entire software infrastructure is basically sequential. Something I’ve been getting into recently is [realizing] that almost all of our algorithms are sequential algorithms, and [we’ve] stumbled across the fact that we’re not teaching parallel anything in school. Our problem is how do we get a concurrent software structure built and how do we get the concurrent algorithms, and is that possible?

Q: What kind of mindset change is going to need to happen for the industry to embrace the necessary changes to a concurrent software structure? How far off is the reality of this?
Mackintosh: I think we are a long way off – it’s a 20-year problem. All you are trying to do in MP SoCs is reverse complex problems in some manner. How you do it can be extremely diverse. The real issue is, “What is the problem?” If you look at it from the top down, and you’ve got infinite time to solve the problem and infinite money, you’d work it from the top down and you’d split it into software solutions, hardware solutions that are economically available to work within your budget of time and money. The reality is that most people start from some fixed position and push that to get to the solution. In fact, everybody is working from bottom up, which is not an optimum solution. So, where do you go? It is a philosophical change that needs to happen. It’s a fundamental issue. If hardware and software were far more interoperable and interchangeable, you’d be able to address things a lot more economically and quickly. Basically, guess what we are missing? Standards to do that. Interoperability is the issue.

Q: Don’t we have to have the definitions and philosophy solidified in order to get to that step?
Mackintosh: The interesting thing is that standards are attempted to be defined after the fact, and then you get a lot of commercial interest, which causes problems with acceptance in the industry. But the reality of it is, standards need to be defined very early on in the process so when you are looking at problem areas, then you look at the types of standards you need to be able to cause things to be reused efficiently. So it’s the beginning of the process, not the end. We should be looking at what we are trying to do, what the ways are to do it, what standards we need to do it, then everything else ripples down…application software, hardware, etc.
Davidmann: I buy that and that’s one of the reasons the Multicore Association exists. But I don’t believe you should standardize stuff which isn’t “cooked.” Standards are sort of like omelets: a good chef won’t give it to you until it’s ready. The challenge is you need the adoption and the de facto things, and then you can standardize. It’s very hard to get a bunch of smart guys in a room and come up with a standard that’s of much use. The practical approach is that you need a ‘straw man’ and you have the time to sort it out.
Mackintosh: What you are talking about is how you make standards adoptable.
Lennard: There’s another point: In successful consortia -- the SPIRIT Consortium and OCP-IP  –  those groups kicked off from a contribution from a company. And it was a commercial contribution that got it moving. The committees ratify – committees are great at ratifying. Making decisions by committee to build something from the ground up is not pointing forward, so the point about cooking is correct.
Davidmann: You need standards to make progress – some by de facto and some by committees. With this concurrent programming, there is no standard or even accepted model of a concurrent programming style and that’s one of the things in the Multicore Association that we are trying to do. There needs to be some examples out there of people doing this, and there are. There are lots in academics; there are lots in big companies. You go talk to the NXPs and the STs – they’ve already got all this stuff inside research programs and in leading-edge development teams. It’s a matter of somehow making this accessible to every chip, not just the big guy because for every fabless startup that puts two, three or four processor cores down, it becomes a complete nightmare. There needs to be much more effort on the programming and software and the tools for multi-core.