3.1. The Framework Structure
The framework structure is presented in Figure 1. It is composed of several tools to increase reusability in several contexts.
The first step of the process is to describe both the target algorithm and the target architecture graphs. A graphical editor reduces the development time required to create, modify and edit those graphs. The role of Graphiti [21] is to support the creation of algorithm and architecture graphs for the proposed framework. Graphiti can also be quickly configured to support any type of file formats used for generic graph descriptions.
The algorithm is currently described as a Synchronous Data Flow (SDF [22]) Graph. The SDF model is a good solution to describe algorithms with static behavior. The SDF4J [23] is an open-source library providing usual transformations of SDF graphs in the Java programming language. The extensive use of SDF and its derivatives in the programming model community led to the development of SDF4J as an external tool. Due to the greater specificity of the architecture description compared to the algorithm description, it was decided to perform the architecture transformation inside the PREESM plug-ins.
The PREESM project [24] involves the development of a tool that performs the rapid prototyping tasks. The PREESM tool uses the Graphiti tool and SDF4J library to design algorithm and architecture graphs and to generate their transformations. The PREESM core is an Eclipse plug-in that executes sequences of rapid prototyping tasks or workflows. The tasks of a workflow are delegated to PREESM plug-ins. There are currently three PREESM plug-ins: the graph transformation plug-in, the scheduler plug-in, and the code-generation plug-in.
The three tools of the framework are detailed in the next sections.
3.2. Graphiti: A Generic Graph Editor for Editing Architectures, Algorithms and Workflows
Graphiti is an open-source plug-in for the Eclipse environment that provides a generic graph editor. It is written using the Graphical Editor Framework (GEF). The editor is generic in the sense that any type of graph may be represented and edited. Graphiti is used routinely with the following graph types and associated file formats: CAL networks [13, 25], a subset of IP-XACT [26], GraphML [27] and PREESM workflows [28].
3.2.1. Overview of Graphiti
A type of graph is registered within the editor by a configuration. A configuration is an XML (Extensible Markup Language [29]) file that describes
(1)the abstract syntax of the graph (types of vertices and edges, and attributes allowed for objects of each type);
(2)the visual syntax of the graph (colors, shapes, etc.);
(3)transformations from the file format in which the graph is defined to Graphiti's XML file format
, and vice versa (Figure 2);
Two kinds of input transformations are supported, from XML to XML and from text to XML (Figure 2). XML is transformed to XML with Extensible Stylesheet Language Transformation (XSLT [30]), and text is parsed to its Concrete Syntax Tree (CST) represented in XML according to a LL(k) grammar by the Grammatica [31] parser. Similarly, two kinds of output transformations are supported, from XML to XML and from XML to text.
Graphiti handles attributed graphs [32]. An attributed graph is defined as a directed multigraph
with
the set of vertices,
the multiset of edges (there can be more than one edge between any two vertices).
is a function
that associates instances with attributes from the attribute name set
and values from
, the set of possible attribute values. A built-in type attribute is defined so that each instance
has a type
, and only admits attributes from a set
given by
. Additionally, a type
has a visual syntax
that defines its color, shape, and size.
To edit a graph, the user selects a file and the matching configuration is computed based on the file extension. The transformations defined in the configuration file are then applied to the input file and result in a graph defined in Graphiti's XML format
as shown in Figure 2. The editor uses the visual syntax defined by
in the configuration to draw the graph, vertices, and edges. For each instance of type
the user can edit the relevant attributes allowed by
as defined in the configuration. Saving a graph consists of writing the graph in
, and transforming it back to the input file's native format.
3.2.2. Editing a Configuration for a Graph Type
To create a configuration for the graph represented in Figure 3, a node (a single type of vertex) must be defined. A node has a unique identifier called id, and accepts a list of values initially equal to
(Figure 4). Additionally, ports need to be specified on the edges, so the configuration describes an edgeType element (Figure 5) that carries sourcePort and targetPort parameters to store an edge's source and target ports, respectively, such as acc, in, and out in Figure 3.
Graphiti is a stand-alone tool, totally independent of PREESM. However, Graphiti generates workflow graphs, IP-XACT and GraphML files that are the main inputs of PREESM. The GraphML files contain the algorithm model. These inputs are loaded and stored in PREESM by the SDF4J library. This library, discussed in the next section, executes the graph transformations.
3.3. SDF4J: A Java Library for Algorithm Data Flow Graph Transformations
SDF4J is a library defining several Data Flow oriented graph models such as SDF and Directed Acyclic Graph (DAG [33]). It provides the user with several classic SDF transformations such as hierarchy flattening, and SDF to Homogeneous SDF (HSDF [34]) transformations and some clustering algorithms. This library also gives the possibility to expand optimization templates. It defines its own graph representation based on the GraphML standard and provides the associated parser and exporter class. SDF4J is freely available (GPL license) for download.
3.3.1. SDF4J SDF Graph model
An SDF graph is used to simplify the application specifications. It allows the representation of the application behavior at a coarse grain level. This data flow representation models the application operations and specifies the data dependencies between these operations.
An SDF graph is a finite directed, weighted graph
where:
(i)
is the set of nodes. A node computes an input data stream and outputs the result;
(ii)
is the edge set, representing channels which carry data streams;
(iii)
is a function with
the number of initial tokens on an edge
;
(iv)
is a function with
representing the number of data tokens produced at
's source to be carried by
;
(v)
is a function with
representing the number of data tokens consumed from
by
's sink node;
This model offers strong compile-time predictability properties, but has limited expressive capability. The SDF implementation enabled by the SDF4J supports the hierarchy defined in [3] which increases the model expressiveness. This specific implementation is straightforward to the programmer and allows user-defined structural optimizations. This model is also intended to lead to a better code generation using common C patterns like loop and function calls. It is highly expandable as the user can associate any properties to the graph components (edge, vertex) to produce a customized model.
3.3.2. SDF4J SDF Graph Transformations
SDF4J implements several algorithms intended to transform the base model or to optimize the application behavior at different levels.
(i)The hierarchy flattening transformation aims to flatten the hierarchy (remove hierarchy levels) at the chosen depth in order to later extract as much as possible parallelism from the designer's hierarchical description.
(ii)The HSDF transformation (Figure 7) transforms the SDF model to an HSDF model in which the amount of tokens exchanged on edges are homogeneous (production = consumption). This model reveals all the potential parallelism in the application but dramatically increases the amount of vertices in the graph.
(iii)The internalization transformation based on [35] is an efficient clustering method minimizing the number of vertices in the graph without decreasing the potential parallelism in the application.
(iv)The SDF to DAG transformation converts the SDF or HSDF model to the DAG model which is commonly used by scheduling methods [33].
3.4. PREESM: A Complete Framework for Hardware and Software Codesign
In the framework, the role of the PREESM tool is to perform the rapid prototyping tasks. Figure 8 depicts an example of a classic workflow which can be executed in the PREESM tool. As seen in Section 3.3, the data flow model chosen to describe applications in PREESM is the SDF model. This model, described in [22], has the great advantage of enabling the formal verification of static schedulability. The typical number of vertices to schedule in PREESM is between one hundred and several thousands. The architecture is described using IP-XACT language, an IEEE standard from the SPIRIT consortium [26]. The typical size of an architecture representation in PREESM is between a few cores and several dozen cores. A scenario is defined as a set of parameters and constraints that specify the conditions under which the deployment will run.
As can be seen in Figure 8, prior to entering the scheduling phase, the algorithm goes through three transformation steps: the hierarchy flattening transformation, the HSDF transformation, and the DAG transformation (see Section 3.3.2). These transformations prepare the graph for the static scheduling and are provided by the Graph Transformation Module (see Section 4.1). Subsequently, the DAG—converted SDF graph—is processed by the scheduler [36]. As a result of the deployment by the scheduler, a code is generated and a Gantt chart of the execution is displayed. The generated code consists of scheduled function calls, synchronizations, and data transfers between cores. The functions themselves are handwritten.
The plug-ins of the PREESM tool implement the rapid prototyping tasks that a user can add to the workflows. These plug-ins are detailed in next section.