-A general dataflow process network (DPN) consists of a network of actors that communicate with each other via statically determined point-to-point buffers. While the general model of computation (MoC) does not impose further restrictions, different classes of DPNs with precise MoCs have been introduced over time. These classes differ in the kinds of behaviors of the actors which affects on the one hand the expressiveness of the DPN class as well as the methods for their analysis and synthesis. A combination of particular classes of DPNs can be effectively used to model and synthesize heterogeneous parallel systems. There are design tools for synthesis that can be conveniently used for implementing individual classes of DPNs, however, they do not support the use of the combination of these DPNs. We therefore envisage a common model-based design flow that allows the modeling of a system based on a combination of particular classes of DPNs, and automatically synthesizes them for heterogeneous architectures. In this paper, we mainly present in detail how the proposed design flow facilitates the automatic synthesis of two individual classes of DPNs by using different code generators for the particular kinds of actors. We therefore first describe the proposed classes of DPNs and then present a common automatic synthesis that details the code generators and the runtime system. Finally, we demonstrate the use of our framework with a simple test case that has been modeled and synthesized individually for each employed class of DPN. Index Terms-model-based synthesis, models of computation, dataflow programming paradigm
A model of computation (MoC) precisely determines why,
when and which atomic action of a system is executed.
Dataflow process networks (DPN) [
A heterogeneous computing system can accompany
different devices including single-core and multi-core processors
with application-specific hardware. At the level of its software
architecture, it may consist of many components concurrently
running on these devices that interact with each other via
particular MoCs. To develop such systems using DPNs, a
heterogeneous combination of particular classes of DPNs can
be effectively used. There exist design tools for modeling like
Ptolemy [
We therefore envision a common model-based design flow
that supports the modeling of a system based on a
heterogeneous combination of particular classes of DPNs, and
automatically synthesizes them to implementations for
crossvendor heterogeneous architectures. In a nutshell, we envision
a model-based automatic synthesis that implements models
using a combination of particular MoCs on heterogeneous
hardware. Based on this overall vision, in this paper, we present
in detail how the proposed synthesis design flow integrates
different individual classes of DPNs in a common framework.
The method mainly focuses on the software synthesis of two
different classes of DPNs that uses different code
generators for the particular kinds of actors. In general, efficiently
synthesizing DPNs for different architectures is a challenging
task as the architecture specification and the runtime for each
target hardware has to be taken into account. To this end, the
common abstraction provided by the open computing language
(OpenCL) [
In summary, we make the following contributions in this paper:
We present a model-based design flow that allows us to model and synthesize two different classes of DPNs, namely the static (synchronous) dataflow (SDF) and the dynamic dataflow (DDF).
Using a formal description of a general dataflow network, we elaborate the specific interpretations of the proposed MoCs.
We present the individual code generators of the proposed SDF and the DDF actors.
We demonstrate the applicability of our framework with a simple test case, modeled and synthesized twice, once based on the SDF and second using the DDF.
We present experimental results to analyze and compare the code size, the total network build time, and the total execution time of synthesized implementations.
Dynamic DPNs are more general in that the order in which
actors are triggered for execution, as well the number of
tokens produced/consumed by each actor on each execution
is decided dynamically at runtime. This allows conditional or
data dependent executions of actors, in particular, each actor
can produce and consume different numbers of tokens in every
firing. This generalization results in higher expressiveness and
flexibility, but makes the analysis more difficult. Examples
of dynamic DPNs are: Kahn process networks (KPN) [
II. BACKGROUND This section first discusses in general the dataflow process networks (DPNs) and their synthesis, and then presents the related synthesis frameworks.
Based on the stated contributions, this paper mainly
emphasizes on the modeling and software synthesis of behaviors
based on individual classes of DPNs. Nevertheless, it also
provides the basis for the future work to support behaviors
based on heterogeneous combination of these DPNs.
A dataflow process network (DPN) [
Although the general model of computation (MoC) does
not impose any further restrictions, many different classes of
DPNs have been introduced over time [
Static DPNs are generally characterized as the ones where the number of tokens produced/consumed by each actor on each execution is specified statically at compile time, and hence actors can be scheduled statically at compile time. On
the one hand, these characteristics allow powerful design-time
analysis techniques (e.g. for predictability and decidability), In this section, we present a few examples of dataflow oriented
but on the other hand they limit the expressiveness by ex- synthesis frameworks:
cluding dynamic behaviors (like select and switch nodes). In [
As discussed, the existing classes of DPNs differ in the kinds
of behaviors of the actors which affects on the one hand the
expressiveness of the DPN class as well as the methods for
their analysis and synthesis. The design tools for modeling
like Ptolemy [
We therefore propose the idea of a common automatic synthesis design flow that allows us to model behaviors based on particular classes of DPNs, and automatically synthesizes them for heterogeneous architectures, mainly by using a combination of different code generators. To this end, this work presents in detail how the proposed approach supports the synthesis of two different classes of DPNs, namely the SDF from static DPNs and the DDF from dynamic DPNs.
This paper mainly focuses on the individual code generators, however, also forms the basis for the future work to use the combination of these generators to support heterogeneous
DPNs.
The DAL framework [
The framework presented in [
Another dataflow oriented framework [
Therefore, the existing frameworks based on DPNs generally provide a single dedicated code generator for supporting synthesis of behaviors based on a particular MoC.
The proposed design flow is systematically organized in two
stages of modeling and synthesis, as shown in Fig. 1. At
first, the modeling stage employs a subset of the CAL actor
language (CAL) [
For the synthesis stage, the framework logically incorporates
the OpenCL specification as an operating system (OS) mainly
because of two reasons: First, it provides an abstraction for
heterogeneous hardware, and second, the framework uses this
abstraction in the composition of the synthesis where different
components implement different low-level details. To this end,
OpenCL distinguishes between a host and kernels where the
host is a centralized entity that is connected to one or more
compute devices (CPU, GPU etc.) and is responsible for the
execution of kernels. Kernels are C-like functions that actually
implement the abstract behavior of the system or part of the
system. Therefore, the framework adopts this idea of hosts and
kernels for the synthesis as shown in Fig 1. Since a general
discussion of OpenCL is out of scope for this paper, we refer
to [
Overall, the modeled behavior based on any proposed class of DPN is provided to the synthesis stage. The synthesis stage incorporates an individual code generator for each DPN class (detailed in Section III-C1), and uses a centralized host (detailed in Section III-C2) that provides different components (including the runtime system) to finally implement the modeled behavior based on the underlying DPN class (MoC) on the targeted OpenCL-abstracted hardware.
In this section, we first formally describe a general dataflow network based on the used subset of CAL, which is then used to specify the execution semantics of the proposed classes of DPNs, namely the SDF MoC and the DDF MoC.
network is an an ordered pair @ = (F; A), consisting of FIFO buffers F and actors A. F (fi; og N) are the available input and output FIFO buffers. Every DPN has a finite number of FIFO buffers F. Input FIFO buffers are defined by Finput = F \ (fig N), and output FIFO buffers are defined by Foutput = F \ (fog N). A is the finite set of actors. Each actor (Fin,Fout; GA) 2 A also has a subset of input FIFO buffers Fin Finput, a subset of output FIFO buffers Fout Foutput, and an associated set of guardedactions GA. The input and output FIFO buffers of an actor are always mutually exclusive, i.e, Fin \Fout = . In general, each DPN actor has firing rules that determine when enough tokens are available to enable that actor. Also, a computation an actor can perform is determined by a function that consumes a finite number of input tokens and produces a finite number of output tokens. To support the modeling of different kinds of behaviors (e.g., synchronous and asynchronous), we further decompose and organize these firing rules and computations of actors in a set of what we call guarded-actions GA. Each guarded-action ga (Fi; Fo; V~i; V~o; ; ) 2 GA has a subset of input FIFO buffers Fi Fin, a subset of output FIFO buffers Fo Fout, a set consisting of sequences of input token variables V~i of Fi, a set consisting of sequences of output token variables V~o of Fo, and two functions and .
Explanation. The code template for a generic actor ’a’ is listed in Listing 1: An actor ’a’ with ’m’ inputs and ’n’ outputs is declared with a finite set of input FIFO buffers (Fin1 to Finm ) and a finite set of output FIFO buffers (Fout1 to Foutn ) with a data type (Line 1). The behavior of this generic actor is specified by a set of actions GA, where each action ga upon execution can consume input tokens, perform some computations on consumed tokens and produce output tokens. For brevity, we list a single example action designated by ’ga1 ’ (Lines 3-12). The action is declared with a finite set of ’t’ input FIFO buffers Fi = fFi1 , Fi2 ..., Fit g (Line 3), and a finite set of ’l’ output FIFO buffers Fo = fFo1 , Fo2 , ..., Fol g (Line 4). Input FIFO buffers Fi are declared with their respective sequences of input token variables V~i = fVi1 ; Vi2 ; :::; Vit g. Each sequence Vij 2 V~i then consists of a finite number of input token variables. For instance, if Fij has a sequence of ’p’ tokens per action execution, the corresponding set of local variables is defined by Vij = fvij 1 ; vij 2 ; :::; vij p g (Line 3). The number of variables (’p’ in this case) determines the token consumption rate of Fij per execution of an action. Similarly, output FIFO buffers Fo are declared with their respective sequences of output token variables V~o = fVo1 ; Vo2 ; :::; Vol g.
~ Each sequence Voj 2 Vo then consists of a finite number of output token variables. For instance, if Foj has a sequence of ’h’ tokens per action execution, the corresponding set of local variables is defined by Voj = fvoj 1 ; voj 2 ; :::; voj h g (Line 4). The number of variables ’h’ denotes the token production rate of Foj per execution of this action.
Listing 1: Code template for a generic actor ’a’. 1 actor a() Fin1 , ... Finm ==> Fout1 , ... Foutn : 2 //guarded action example 3 ga1 : action Fi1 :[vi1 1 , vi1 2 ... vi1 p ], ... Fit :[vit 1 , vit 2 ... vit q ] 4 ==> Fo1 :[vo1 1 , vo1 2 ... vo1 g ], ... Fol :[vol 1 , vol 2 ... vol h ] 5 guard 6 vi1 1 > 1 and vit q < 0 and vit 1 ... 7 var 8 vo1 1 , vol h ... 9 do 10 .v..o1 1 := vi1 1 *2 + vi1 1 *vit 1 ... 11 12 end 13 ... 14 gax : 15 ... 16 end
The function : EB(V ) ! B is a Boolean function of an action that evaluates a finite set of Boolean expressions EB = fEB1 ; EB2 ; :::; EBn g applied on the individual input token variables, to a Boolean (B = f0; 1g), where V S V~i. : Vi ~ jFoj is a firing function of an action that upon firing ~ jFij ! Vo consumes tokens V~i from Fi and produces tokens V~o to Fo.
Execution Conditions. There exist two minimal conditions (mc) for any action ga to fire. (1) There should be sufficient input tokens V~i available to bind Fi to appropriate values. (2) There should be sufficient room for the output tokens V~o in their respective output FIFO buffers Fo. For an action ga that requires input tokens to have particular values, an additional condition can be specified using a guard (Line 5). A guard consists of a set of Boolean expressions (EB) that are applied on a set of individual input token variables V (Line 6). The combined evaluation of EB is represented by the function . The computations an action can perform in the form of the firing function are defined within do/end blocks (Lines 9-12).
Restrictions. Based on the used subset of CAL, we also consider following restrictions: (1) The actions (GA) are always evaluated for execution sequentially in the same order of their definitions. (2) Generally, Fi and Fo can be overlapping across different actions, however, guard-conditions are always exclusive. This ensures that for each execution of an actor, the actions will never compete for an execution for any set of data values (tokens).
2) The SDF Execution Semantics: The SDF MoC [
Each actor (2 A) in @ is triggered for an execution if and only if sufficient input data is available for all its guardedactions and sufficient space is available for the outputs of those actions. The data rate and the data path of an actor in each execution remain the same. Upon an execution, for each guarded-action (2 GA) of an actor, V~i is consumed, and guard is evaluated using the function . In case if guard holds, the corresponding action is executed which performs a computation, and finally produces an output V~o of that action based on the firing function . Overall, each actor execution consumes a fixed number of tokens from all input FIFO buffers (Fin), and produces a fixed number of tokens for all output FIFO buffers (Fout). Hence, the proposed SDF MoC is intrinsically deterministic.
allows one to model dynamic and asynchronous actors. To this end, each actor (2 A) in @ is triggered for an execution if there is input data available for any input FIFO buffer and if space is available for any output FIFO buffer of that actor. The data rate and the data path of an actor can change per execution depending on which action is executed. At first, for all actions GA of an actor, V~i is peeked from Fi, and Fo is checked for space based on V~o. Next, for each ga 2 GA of an actor, guard is evaluated using the function , and an additional implication ( ; mc) ) V is evaluated, where represents a combined evaluation of all Boolean expressions, and mc represents the evaluation of minimal conditions to fire an action as discussed in Section III-B1. Based on that, this implication that forms the basis of making decisions dynamically at runtime about whether to execute an action and consume/produce data tokens, is evaluated based on the conditions as shown in Table I. In case if the implication is evaluated to one, the corresponding action is executed which consumes the peeked tokens from Fi, performs a computation, and finally produces output tokens in Fo of that action. On the contrary, if the implication is evaluated to zero i.e., if at least one of the minimal conditions is false, the peeked tokens from Fi are not consumed and the action is not executed. Finally, if is evaluated as false for an action, the implication is evaluated to a don’t-care state ’x’.
As each actor upon execution is permitted to check Fin by peeking before it can be finally consumed, thus allows a nonblocking read. This makes the proposed MoC more flexible, however, may lead to non-deterministic behaviors e.g., a nondeterminate merge.
Listing 2: SDF based generated code of an action from the actor ’a’ as illustrated in Listing 1.
/*ga by ga execution:*/ /* ga1 /* /*step1: read all inputs for an action*/ fifoRead(Fi1 , buf Fi1 , p, gid, &cnt Fi1 ); .v..i1 1 = buf Fi1 [gid*p + cnt Fi1 .current count]; fifoRead(Fit , buf Fit , q, gid, &cnt Fit ); vit q = buf Fit [gid*q + cnt Fit .current count]; /*step 2: evaluate guard expressions EB*/ guard vi1 1 = (expression) ? true: false; ... guard vit q = (expression) ? true: false; /*step 3: execute guarded action*/ if(guard vi1 1 && guard vit q && ...) f /*do end*/ vo1 1 = vi1 1 *2 + vi1 1 *vit 1 ... ; bytes = fifoWrite(Fo1 , Vo1 , ..., gid, &cnt Fo1 ); ...
g
As discussed, the synthesis stage uses different components, as shown in Fig 1, and finally implements the modeled behavior based on the underlying DPN class (MoC) on the targeted OpenCL-abstracted hardware. This section explains in detail different components of the synthesis stage.
1) Code Generators: Each code generator is a core component of the framework that generates code strictly based on the semantics of the underlying DPN class and the OpenCL specification. Based on the OpenCL paradigm, the code generator supplied with a CAL description generates an OpenCL kernel for each actor of the network, as shown in Fig 1. This section explains the code generation of the kernels based on the proposed classes of DPNs, namely the SDF and the DDF, as were introduced in Section III-B.
Fig. 3: The algorithm for the DDF MoC based code generation.
generation based on the proposed SDF MoC is shown in Fig. 2.
Assuming that the generic actor ’a’ as illustrated in Listing 1, is a synchronous (static) one, the generated code based on this algorithm is depicted in Listing 2. For brevity, we only show the generated code for the example action ’ga1 ’ from Listing 1.
(1) The code generator sequentially iterates through available actions (GA) of an actor, where for each ga it proceeds as follows: (2) It generates code that read (consume) all the input tokens V~i from Fi. For this purpose, it inserts a fifoRead for each input FIFO buffer for reading tokens, and generates code that assign each token to its corresponding variable (Lines 38). (3) Next, the code generator generates code for evaluating all the Boolean expressions EB of a guard (Lines 9-12). (4) Finally, it generates code that evaluate the combined Boolean result (Line 14), and if true, execute the corresponding action where all the defined computations are performed including writing output tokens to the associated output FIFO buffers (Lines 15-18). For each output FIFO buffer, a fifoWrite is inserted for writing tokens based on the specified output token variables Voj . Overall, the code generator follows a ga-by-ga execution scheme until there is no more ga left.
b) Code Generation DDF: The algorithm for the DDF MoC based code generation is shown in Fig. 3. Using this algorithm, the generated code for the generic actor ’a’ as illustrated in Listing 1, is listed in Listing 3. For brevity, we only show the generated code related to the example action ’ga1 ’ from Listing 1.
(1) The code generator first generates code that peek all the input tokens V~i for all actions from all the input FIFO buffers Fin. To this end, for each input FIFO buffer, it inserts a fifoPeek (Line 2), and generates code that assign each token to its corresponding token variable (Line 3). (2) It then generates code that check if there is sufficient space available in each output FIFO buffer based on the number of output token variables. For this purpose, a CTRLBITDynamic with a parameter ”get” is used for each output FIFO buffer (Lines 5-7). (3) The code generator then proceeds in a ga-by-ga execution scheme until there is no more ga left. For each ga in an actor, the code generator works as follows: (4) It generates code that evaluate all the Boolean expressions EB of a guard (Lines 1012). (5) Next, it generates code that determine the implication ( ; mc) ) V . For this purpose, the evalImplication( , mc) is inserted that finally evaluates the implication (Lines 13-14). (6) Next, the code generator generates code that execute an action based on the evaluated implication from (5). To this end, the generated code uses the results of the implication Fig. 4: Actor’s invocation-mechanism. to decide whether to execute an action or not (Lines 15-27).
If the final result evaluates to ’0’, it implies that although holds true, at least one of the input/output FIFO buffers of object for each actor that provides the desired information that action does not have sufficient data/space available. For to the host such as, the associated FIFO buffers, the actor’s this purpose, a CTRLBITDynamic with a parameter ”auto” status (idle, running or blocked), the associated kernel, etc. is used (Line 17), that determines whether each input/output Moreover, the host also creates a Device-Queue using the FIFO buffer has sufficient data/space or not, and updates the OpenCL specification that lists all the available devices of buffer accordingly. On the contrary, if the final result evaluates the target hardware. Each element of this queue provides a to ’1’ (Line 20), it implies that an action is ready to execute. command queue of a device, where the actors can be mapped To this end, the corresponding action is executed where all the for execution as shown in Fig. 4. Each command queue can defined computations are performed including writing output represent a complete device (e.g., a CPU) or even a compute tokens to the associated output FIFO buffers (Lines 21-26). For unit of that device (e.g., a CPU-core). each output FIFO buffer, a fifoWrite is used for writing tokens The Runtime-Manager, as shown in Fig. 1 and Fig. 4, based on the specified output token variables Voj (Line 23). is a part of the host that exploits different components and Similarly for each input FIFO buffer, a CTRLBITDynamic provides: the schedulers for scheduling actors based on the with a parameter ”clear” is used to update the buffer for proposed SDF and the DDF MoCs, the communication mechconsumed tokens (Line 25). anism between the host and kernels, a dispatcher for mapping actors to devices, and the status update mechanism using Listing 3: DDF based generated code of an action from the specialized callbacks. actor ’a’ as illustrated in Listing 1. Scheduling and dispatching. As the main vision of the 1 /*peek all input ports for all actions. Returns ctrl bits automatically*/ proposed design flow is to support the heterogeneous com23 cvtir1l 1Vi=1 b=uffifFoPi1ee[gki(dF*ip1 +,bcunft FFii11,.cpu,rgreidn,t &cocunntt]F; i1 ); bination of particular DPNs, we developed schedulers for the 4 ... used classes of DPNs using a common dynamic round robin 56 /c*tralllVoou1tpu=t CctTrlRbLitBsITfoDr ysnpaamceicc(hFeoc1k*,/”get”, Fo1 >tail + gid, &cnt Fo1 , g); scheduling scheme. Based on the used MoC, the Runtime7 ... Manager invokes the corresponding scheduler that iterates 89 //**ggaa1 b/*y ga execution:*/ through the Actors-Queue in a round robin fashion, and looks 10 /*step 1: evaluate guard expressions EB and determine action implication*/ for an actor that is ready for execution. To this end, the 1112 .g..uard vi1 1 = (expression) ? true: false; scheduler based on the proposed SDF MoC examines each 13 ev impl g a 1 = evalImplication(guard vi1 1 && guard vit q ..., actor based on the semantics explained in Section III-B2. 1154 /c*trslteVpi21: e&x&ecuctterlgVaitby&(&;cmtrlc)V)o1 V&&(incttrhleVoorld)e;r: ’0’, ’1’)*/ Similarly, the scheduler based on the proposed DDF MoC 16 if(ev impl g a 1 == ’0’)f tests each actor for execution based on the semantics discussed 1187 .C..TRLBITDynamic(Fi1 , ”auto”, Fi1 >head + gid, &cnt Fi1 , p); in Section III-B3. Following the underlying semantics, the 19 g invoked scheduler fetches a ready actor from the list. Re2210 if(evviom1p1l =g vai11 1=*=2’1+’)vfi1 1 *vit 1 ... ; gardless of which scheduler is evoked, the Runtime-Manager 22 ... then examines the Device-Queue and finds the device with 2243 .b..ytes = fifoWrite(Fo1 , Vo1 , ..., gid, &cnt Fo1 ); the least weight (i.e., a device assigned with least number of 25 CTRLBITDynamic(Fi1 , ”clear”, Fi1 >head + gid, &cnt Fi1 , p); actors), and dispatches the fetched actor on that device. The 2267 g ... goenntehreatuesdekdeMrneolCo.fAthsethdiissppaatpchereddoacetsonroist tfhoecnusexoencuptreedsebnatsinedg 2) Centralized Host: As shown in Fig. 1, the centralized efficient mapping of executions on devices, therefore, a simple host of the framework is further composed of essential com- weighted dispatching scheme is employed. ponents that work together for implementing low-level details Communication and the status update mechanism. The such as the scheduling policy, the communication mechanism, communication between the host (FIFO buffers) and kernels is resource allocation, etc. One of such components is a queue of realized using OpenCL buffers. For each bounded FIFO buffer, actor objects denoted as Actors-Queue, generated by the code an OpenCL buffer is created with the same structure and size generator for the host. The Actors-Queue contains a special of the FIFO buffer. Moreover, a status update mechanism is developed using callbacks as shown in Fig. 4. The RuntimeManager generates a callback interface each, for every existing device in the Device-Queue. The scheduler sets up a callback event for each fetched actor and links it with the callback handler of the device where it is dispatched. Hence, the completion of the kernel of the dispatched actor automatically notifies the Runtime-Manager by invoking the callback handler of the used device. The callback handler performs a set of tasks including: retrieving data from the kernel (OpenCL buffers), updating all the FIFO buffers of the actor, updating the ActorsQueue as well as device’s load, updating the OpenCL buffers and so on. The FIFO buffers are updated differently for the proposed SDF and the DDF MoC. Based on the SDF MoC, the data rate of an actor remains fixed in each execution, and therefore each FIFO buffer is simply updated based on the specified static data rate. On the contrary, based on the DDF MoC, the data rate of an actor can change per execution.
Therefore, the data rate of each FIFO buffer per execution is first computed and finally each FIFO buffer of the actor is updated accordingly.
The ConceptCar is an experimental vehicle with the objective of testing and verifying modern future car features by deploying different classes of applications. The ConceptCar currently has 8 different ECUs, where each ECU is responsible for a specific operation.
To validate the ability of the framework to produce implementations based on employed MoCs, we present a preliminary test case, namely the dataflow emulation of the Speedometer. The Speedometer is an application originally developed for one of the ECUs of the ConceptCar, namely the sensor board steering ECU. The basic hardware design of this application is shown in Fig. 5, where the main idea is to retrieve the frequency of pulses from the sensors (photo-transistors) attached to the front-right (FR) and rear-left (RL) wheel, and to compute the current speed accordingly. The Speedometer accounts for the over-speeding by turning the LED indicator on. The dataflow model for emulating the Speedometer behavior is shown in Fig. 6. The actors S1 and S2 provide sampled sensor data, measured by the hardware counters of the sensor board ECU, and collected through the centralized CAN bus of the
Fig. 7: Code size and network build time.
ConceptCar. Based on this data, the actor F1 computes the current speed by using the algorithm developed for the sensor board ECU. Next, the measured speed (in meters per second) is tested by the actor F2 against a threshold value for identifying over-speeding. Finally, the actor A1 displays the over-speeding status based on the data values provided by F2. Each modeled behavior of the Speedometer based on the individual class, i.e., the SDF and the DDF, is then synthesized to the corresponding implementation. The generated implementations are executed on the OpenCL-abstracted target hardware and the experimental results are collected.
As discussed, dataflow behaviors of the Speedometer are synthesized by the proposed framework to different implementations based on the proposed SDF and the DDF MoC. This preliminary test case thus allows us to observe and analyze the generated implementations for the resulting code size, the total network build time, and the total execution time taken by the complete network for the specific sample sizes.
To this end, the generated code size of each dataflow actor and the total build time for the complete network is depicted in Fig. 7. In contrast to the proposed SDF MoC, where the data rate of each actor per execution is specified statically at compile time, the proposed DDF MoC offers a more flexible semantics, where the decisions on whether to execute actions and consume/produce data are taken dynamically at runtime. Consequently, the latter one accommodates additional code for writing the consumption/production status of data tokens Fig. 8: SDF vs DDF. for each execution of an actor at runtime. This overhead can therefore be observed from the number of lines of the generated code for each actor and the total network build time for each implementation, as shown in Fig. 7. The generated code based on the DDF MoC for the complete network is approximately 40% greater than based on the SDF MoC, resulting in an additional build time overhead of more than 115%.
Moreover, to analyze and to compare the performance of the proposed MoCs of the framework, the total execution time (in milliseconds) for the complete network is measured against the number of samples (sensor data), as shown in Fig. 8. Based on that, the additional runtime overhead associated with the DDF MoC is propagated to the total execution time of the network, resulting in elevated execution times. As the number of samples increases, this effect induced by the overhead can be clearly observed as shown in Fig. 8. The proposed DDF MoC although offers semantics to model more flexible and data dependent behaviors, but at the cost of the additional runtime overhead. Therefore, it exhibits a trade-off between flexibility and overall performance.
In this paper, we have presented an automatic model-based design flow to provide synthesis of dataflow behaviors based on the synchronous dataflow (SDF) and the dynamic dataflow (DDF) MoC. The complete design flow including modeling, synthesis and the execution has been explained in detail. To this end, an abstract notion of a dataflow network is introduced which then used differently to formally explain the proposed classes of DPNs. An abstract notion of an actor is used to describe in detail the code generators of the considered MoCs. The complete synthesis scheme including the runtime manager is explained, where all the low-level implementation details are presented. We demonstrated the proposed synthesis design flow by a preliminary test case based on an automotive research platform. The experimental results are carried out based on the code size, the network build time and the total execution time for each implementation.
Overall, the presented work emphasized on the synthesis of individual classes of DPNs. Future work will support the synthesis of heterogeneous DPNs, i.e., where a combination of different DPN actors is allowed. Also, we plan to extend the framework with further classes of DPNs.