MP-SoC Programming

In the literature, a variety of different tool flows have been developed to program MP-SoCs. One category are the classical compiler-based approaches, e.g., MAPS [183], Compaan [251]. A con- ventional sequential language, for instance, C, C++, or Matlab, is used as the initial application- specification from which the compiler automatically extracts parallelism. To ease the job of com- pilers, explicit Application Programming Interfaces (API) for instance, Message Passing Interface (MPI) [16], Open Multi-Processing (OpenMP) [22], Task Transaction Level (TTL) interface [258] or Portable Operating System Interface (POSIX) [14], are often used to identify data-independent blocks of code within an application. The major problem of compiler-based approaches is that the

32 Chapter 2. An Overview of Network Processors

level of abstraction of the underlying hardware exposed to application programmers is often too low, thereby lacking a uniform and scalable manner to specify concurrency of computation and communication of an application. The consequence is that system-level verification and software synthesis of a target system are often difficult.

An alternative are MoC-based approaches. By restricting an application to a certain MoC, the semantics of computation and concurrency can be mathematically defined. As a result, quanti- tative analysis pertaining to, for instance, schedulability tests and worst-case behavior, can be tackled in a reasonable manner. Furthermore, software synthesis can be applied, i.e., automati- cally generating implementations, whose behavior is consistent with the abstract model behavior. Despite this, it is quite unlikely that a general revolutionary change of programming paradigm will occur in the near future, and as such the C programming language will continue to dominate among embedded software developers (with parallel extensions, e.g., pthreads [14], OpenMP [22]) [79]. However, DSLs have been gaining momentum, especially if they build on top of well known languages and if there is a clear road to migrate legacy code [79].

Amongst other MoCs, the Kahn Process Network (KPN) [167] and its ramifications are widely used, because of their simple communication and synchronization mechanisms as well as coarse- grain parallelism. Besides this, many other tool flows, for instance, Ptolemy [25], Metropolis [55], Koski [168], and Artemis/SESAME/DAEDALUS [214, 221], have been described in the literature. The most well-known subclass of KPN is Synchronous Data Flow (SDF) [180, 181] that enables static analysis of the specified application during compile time. Tool flows based on SDF are, for instance, SHIM [104], PeaCE [HKL+ 07], and StreamIt [TKA02]. Furthermore, Ptolemy [25] supports heterogeneous modeling and Metropolis [BWH+ 03] defines a meta-model that can be refined into a specific MoC.

Distributed Operation Layer (DOL) is a design flow for Model-Driven Development (MDD) [1] of multiprocessor streaming applications, which has been developed at the ETH Zurich in the context of an European research project called Scalable Software/Hardware Architecture Platform

for Embedded Systems (SHAPES) [219]. The programming model of DOL can be described as

a concrete instance of a dataflow process network MoC [180], which is a subclass of KPN [167]. Basically, a dataflow network process expresses an application as a set of parallel autonomous processes – called actors – that communicate exclusively via point-to-point FIFO queues. The actors’ task is to map a set of input streams to a set of output streams. In this context, the developers describe computation by implementing individual, sequential actors that manipulate data streams and coordination by the connection of actors using FIFO queues.

Contrary to the original model introduced in [180], the process network model used in DOL applies finite capacity channels for the FIFO queues, which raises the question for deadlock prevention. However, according to the designer’s (of DOL) experience, such deadlocks (caused through finite communication queues) are quite unlikely [146].

2.5. Programming Network Processors 33 To allow for reusing existing legacy code, actors are implemented in C++. For communication, actors can access ports that serve as an interface to the FIFO queues. The Extended Markup

Language (XML) is used for describing the topology of a dataflow process network, i.e. the

instantiation of actors and their connection by the FIFO queues.

MP-SoC Application Programming Studio (MAPS) aims to reduce the gap between growing software requirements of contemporary embedded systems and current software produc- tivity. [183] claims to provide solutions to several problems a designer is faced with, like partition- ing of legacy code, parallel programming through KPNs. The MAPS flow receives applications written in C syntax and processes these within several phases. Initially, applications are parsed into an IR (analysis phase), while the application code is instrumented to obtain runtime traces. These traces are used to provide dynamic information, which is annotated to the control and dataflow edges of the IR to steer partitioning [81]. A subsequent semi-automatic partitioning

phase allows for identification of independent code blocks. Each application is further analyzed

during a mapping and scheduling phase producing scheduling configurations for each of them. A multi-application analysis phase utilizes these configurations to analyze different application scenarios in accordance to a so called Application Concurrency Graph (ACG). Once the user is satisfied with a configuration for a given multi-application scenario, he can proceed to the code

generation phase to evaluate the results.

HOPES is a parallel programming framework based on a novel programming model, called

Common Intermediate Code (CIC) [177]. In a CIC, the functional and data parallelism of ap-

plication tasks are specified independently of the target architecture and the design constraints. Information on the target architecture and the design constraints is separately described in an XML-file, called Architecture Information File. Based on this information, the programmer maps the tasks to the processing components, manually or automatically. Then, the CIC translator automatically translates the task codes in the CIC model into the final parallel code following the partitioning decision.

DAEDALUS is a tool-suite and methodology [213, 215] targeting the automated design, pro- gramming, and implementation of MP-SoCs. Starting from a functional specification of an appli- cation (written in C), several specifications are derived (the latter two specifications are obtained from DSE through the SESAME tool [221]):

• a MoC-based application-specification capturing its parallel form in terms of a KPN. This specification can either be created manually or generated by a tool called PNGen [260]. • a platform specification describing the topology of an appropriate MP-SoC

• a mapping specification defining a mapping between code blocks (defined in the application- specification) and platform elements (defined in the platform specification)

34 Chapter 2. An Overview of Network Processors

These specifications serve as input for the ESPAM tool [214], which delivers – amongst others – a hardware (synthesizable VHDL code) description of an MP-SoC and appropriate high-level language code to realize the application on the processor cores of the MP-SoC.