By Mieke Van Bavel and Michel Tilman, Interuniversity Microelectronics Centre (IMEC), Leuven, BelgiumEmbedded.com (07/06/08, 12:00:00 PM EDT)
Multiprocessor system-on-chip (MPSoC) platforms have recently raised the industry's expectations as they promise to meet the high-performance targets for multimode multimedia terminals without giving up the requested flexibility.
However, writing software for MPSoC platforms is not straightforward. Designers are used to writing sequential applications in C code and optimizing these applications for embedded platforms. But transforming these sequential programs into functionally equivalent (in other words, correct) parallel programs is a time-consuming and error-prone job.
The C language provides much expressiveness to specify what a program must do, but it's this expressiveness that makes C programs hard to analyze and transform. What's more, customers want these parallel programs to perform at optimal levels while efficiently using MPSoC platform's resources, such as power consumption and bandwidth usage.The realities of source code and parallelization
It's an illusion to think we can take any piece of sequential code and hope that we can transform this code into an efficient parallel version, just like that. In fact, heavily optimized sequential code bases are often not the most appropriate candidates to start with in the first place. And to make matters worse, we want to explore different types of parallelizations quickly and easily, without rewriting significant parts of the program over and over again. Tools can help us in transforming the source code, but in the end, there is no silver bullet: either the designer or the tool (or both) must sufficiently "understand" the source code to be able to transform it correctly and efficiently. Hence, it's crucial that we identify those constructs in the source code that hamper this process. These can be code constructs at the level of programming language idioms or even at the level of design patterns for parallel programming. Once we've identified these constructs, we may elaborate rules that specify in which circumstances these constructs should be avoided.
This is the rationale of IMEC's so-called CleanC rules that have been elaborated during the development of an MPSoC application-mapping tool suite. These rules target ANSI-C language idioms that make the process of mapping sequential C programs onto an MPSoC platform more difficult. They consist of a few tens of guidelines and restrictions. Code restrictions are constructs that aren't allowed to be present in the input C code for the tools to work (on that part of the code).
For instance, undisciplined use of preprocessing information in C can make life very hard for any kind of source-code transformation tool. Code guidelines describe how code should be written to give the tools maximum accuracy and transformation freedom. The majority of these rules transcends the specific functionality of the IMEC mapping tools and may form the basis for a standard set of guidelines for programming MPSoC platforms in a "clean" code called CleanC.
Click here to read more ...