A week of presentations at the recent Multi-Processor SoC (MPSoC) conference made one point clear: A lot of work is going into hardware development for next-generation systems-on-chip, but we don't have a very good idea of how we're going to program these complicated chips.
Any computing platform must have a programming model, which defines how software is developed to run on the platform. A good model uses abstractions to hide some of the details of the underlying execution platform. At the same time, it lets the programmer fully use the hardware's capabilities.
But as MPSoC speakers pointed out, existing programming models don't work well for complex SoCs. What's needed are new programming models that can better abstract hardware-software interfaces and interactions, as well as CPUs, which define those interfaces.
At the Tima Laboratory in Grenoble, France, a "service-based component model" is in development that can abstract both hardware and software elements. The idea is to separate functional service from the way it is physically accessed, creating a single model that can represent everything from an abstract specification to RTL code.
When you put multiple CPUs on an SoC, you want a parallel programming model to take full advantage of the hardware. There's interesting work along those lines at the St. Petersburg State University of Aerospace Instrumentation (Russia). Focusing on both task-level and procedure-level parallelism, this group has developed a set of "asynchronous growing process" models along with Visa, an interactive, graphical parallel programming language that uses these AGP models.
Philips Research is also working on parallel-programming models for multiprocessor SoCs. Because current programming models are too low-level, Philips is promoting "interface centric" design at what it calls the "task transaction level."
With all the companies addressing the SoC market with intellectual property, tools and services, it seems we should be hearing more about programming models. Recently, some very impressive multiprocessor SoCs have entered the market, such as IBM's Cell processor. Several sessions at MPSoC described the hardware design of the Cell, but not much was said about the programming model.
If you're part of an SoC design team, there's a provocative question you might ask at your next design review meeting. Sure, we can put multiple processors, memories, peripherals and a really fast bus structure on this SoC. But will our customers actually be able to program this SoC and take advantage of all this cool hardware we're creating?
Richard Goering (firstname.lastname@example.org) is group editorial director for design automation at EE Times