Wanted: Compilers
for Utilizing MPSoCs
Abstract
Behind every successful processor there is a compiler team making
sure that application developers’ sources are translated reliably
to efficient machine code. While anyone who has ever taken a 101-level
course in computer science knows what a compiler is, at least in
general terms, very few experience the realities of producing a
compiler and a complete tool chain for an architecture.
This panel session provided insight into the economics of compiler
technology, its place in the engineering portfolio, and its role
in the semiconductor ecosystem, especially when it comes to MPSoCs.
Panelists
• Rainer Leupers, RWTH Aachen (Moderator)
• M. de Lange, ACE Compiler
• G. Smith, Gary Smith EDA
• R. Lauwereins, IMEC
• C. Rowen, Tensilica
• Y. Paek, Seoul University
Compilers and Moore’s Law
Older readers might remember that DATE used to be all about hardware
design automation. This has definitely changed.
This very interesting panel discussion on software compilers was
moderated skillfully by Rainer Leupers. It highlighted the technical
and commercial aspects of the compiler necessities associated with
modern multi-processor systems.
In the past, the design and implementation of special compilers
for the various processor types (RISC, DSP, VLIW, etc.) has been
well understood. Now, the next level of complexity is approaching.
Due to the enormous potential of 65nm/45nm technologies, we now
need compilers for Network Processing Units (NPU), reconfigurable
architectures, and Multi-Processor Systems-on-Chip (MPSoC) for heterogeneous
as well as homogeneous systems.
“ESL is more than the traditional view of C-to-Assembler
compile. It’s mapping systems into hardware.”
Gert Goossens, Target Compiler
Technologies (from the audience)
The gap is widening between the requirements of software on one
hand and the complexity of hardware on the other. Hardware engineers
are accustomed to designing concurrent systems. Software, however,
is currently written in a sequential way. Mapping software tasks
to parallel
hardware will be the challenge for a highly sophisticated compiler
or a compiler hierarchy (i.e. a compiler on top of much simpler
compiler). Participants strongly advocated the position that a new
language has to be developed, because C-derivatives cannot properly
handle the concurrency aspect.
Apart from the technical problems that come with NPU and MPSoC designs,
there are also cultural and economic issues that have to be considered.
Since hardware and software cultures are converging, conflicting
points of view have to be harmonized. Where hardware engineers tend
to expect architecture-friendly compilers, system and software engineers
demand compilerfriendly architectures. There is certainly a strong
need for interdisciplinary higher education along these lines.
On the other hand, a compiler in the current software world is expected
to cost some 3 k$ for a perpetual license. The panel agreed, that
the price of the MPSoC compilers that will be needed in the future
will have to be in the range of 45 k$ to 75 k$ to cover development
costs.
According to Chris Rowen, such costs could potentially be hidden
by license fees and royalties of the closely coupled processor system
that comes with the specialized compiler. Nevertheless, Martijn
de Lange argued that this could only be a short-term solution. In
the long run, the price of a compiler license must justify its development.
There is heavy economic pressure for these tools. Gary Smith estimated
this to be a 2 B$ market, which means that there is a significant
amount of money to be earned. On the other hand, not being able
to provide these tools in the near future might bear the risk of
stopping Moore’s Law. So for the time being, scheduling software
on MPSoCs will probably involve a manual approach.
When we take into account that a new software design paradigm is
also necessary and that a new language has to be evolved, the need
for
concentrated activity on the part of the development community and
standardization bodies becomes obvious. Driving such an approach
requires a significant investment, and no company can raise these
funds on its own.
For this reason, efforts have to be combined to drive technology
in the direction of an automated multi-processor software compiler
and tool
chain, which would probably sit on top of a new software design
language.
This brings us back to the educational issue: The designer’s
mindset must be neither hardware-driven nor software-driven. Instead,
designers
need a clear understanding of system development in terms of hardware/software
co-design and targeting of parallel software to multi-processor
systems.
Conclusion
The technology shrink to 45nm enables Multi-Processor Systems-on-Chip
(MPSoC), however, current software languages and the respective
tool chains are not prepared to handle automated software scheduling
and partitioning on MPs. On top of this, today’s system designers
suffer from insufficient education, which is either software or
hardware based. Consequently, they are not prepared to attack parallel
software development.
These issues – together with the commercial burden that comes
with the need for a new hardware / software system development paradigm
– can
only be solved through a concentrated effort on the part of industry,
education, and standardization bodies.
This very interesting panel session might have been the first step
in the right direction.
Author
Peter Neumann, edacentrum
Peter Neumann
|
