1 Introduction

In this paper we propose a new approach that allows one to argue and discuss the results achieved so far by [7], which investigate the minimizing buffer requirements under rate-optimal schedule in Regular Dataflow Networks. Our methodology is devoted to the construction of static schedules for Digital Signal Processing Systems presented by Synchronous Dataflows (SDF) with different rates (known as Multi Rate Dataflows) and to foreseen the total amount of buffer memory of SDFs along with per arc space allocation. In [6], Govindarajan et al. call this type of dataflows Regular Stream Flow Graphs to highlight the nature of the token flow in the arcs. The mapping proposed in [11] can be seen as a natural bridge between the two domains (Petri nets and Dataflows) in investigating the buffer memory requirements, moreover one can also measure the activity duration’s on the Petri net side. The limited resource of a system is a natural issue and the claim for their availability during system’s activity must be foreseen to preclude exhaustion of resources. Therefore this occurrence inhibits system evolution and blocks it.

The paper is divided in four topics. After a summarized overview of the supporting formalisms being investigated by the authors (dataflows and Petri nets), Section 2.2. addresses the main topics behind the mapping bridge outlined between dataflows and Petri nets, followed by a summarized overview of the tools and computational environments used to develop and simulate the resulting Petri net models. In Section 3, the discussion and results achieved so far are point out and used to identify misjudgment concerning the total buffer requirement for a schedule in Synchronous Dataflows. And finally in Section 4. conclusions are highlighted to emphasize the added contribution about the foreseen memory requirements for SDFs using the proposed approach by Rocha et al. [11].

2 Petri Nets, Dataflows and the Proposed Translation Mapping

In order to explain our mapping strategy gathering Synchronous Dataflows and Petri nets, at first a summarized background of both issues is presented. Afterwards, in Section 2.2 a short presentation about the proposed mapping between Synchronous Dataflows and Petri nets is depicted to illustrate our reasoning about the mistaken and erroneous results reached so far by [7].

2.1 Petri Nets and Dataflows

Petri nets (PN) are a modeling formalism that capture the behavior of concurrent and/or distributed systems, allowing synchronization of processes [3, 9]. Nowadays system practitioners can develop the modeling, analysis and simulation of the systems not only supported by the well established mathematical representation of PN but also under graphical environments [2]. In a graphical representation, a Petri net encompasses places, transitions, directed arcs and tokens. Petri nets are bipartite graphs since it is only possible to establish a directed connection (an arc) between a transition and a place or a place and a transition. Places are usually represented by circles or ellipses and model conditions, states, resources or objects. Transitions models events, actions or activities in a Petri net and are denoted by rectangles or boxes. Directed arcs may have attached a natural number, accounting the amount of tokens carried by the arc. An example of Petri net is sketched in Fig. 1. In a dataflow representation [4] a program is composed by two components, vertices known as actors accounting for computations and edges expressing First In First Out (FIFO) queues to hold data values which are embodied in objects known as tokens. Afterwards Lee et al. [8] in 1987 presented Synchronous Dataflows (SDF), a particular set of dataflow where at compile time the number of tokens consumed/produced by an actor on each edge (arc) are known. This way a further improvement about runtime overhead can be achieved. Graphically actors in a dataflow are denoted by circles (squares or rectangles) whereas edges by directed arcs along with nonnegative integer weights posted at its input and output actor ports. These weights express the firing rates (production/consumption) of each actor. Each actor has a fixed number of inputs arcs and a fixed number of output arcs. Figure 2 shows a dataflow network with six actors (a, b, c, d, e and f).

Figure 1
figure 1

Petri net place-transition equivalent model of example RSFG, from [7], page 210.

Full size image
Figure 2
figure 2

Synchronous dataflow of spectrum analyser.

Full size image

2.2 The Proposed Translation Mapping

In both modeling environments (Petri net and Dataflow) one can find elements with similar nature; elements which are passive and those that embody activity. On the side of Petri nets (Dataflows) one can find places (arcs) and transitions (actors), respectively. Arcs carry tokens representing any kind or type of values. Both environments may have weights and initial markings which have a direct match under our methodolgy, as one can see in Fig. 3. These translation rules were applied by Rocha et al. [13] in multirate systems to foresee the amount of allocated resources as well as to expose the effective and maximum potential number of tokens per arc under a cyclic and continuous flow of data. In this context, after the conversion of a dataflow into a Place/Transition (P/T) Petri net (please refer to [5]), a structural analysis is performed to attain the invariants, commonly known as P(lace)-invariants and T(ransition)-Invariants. With P-Invariants, the required amount of memory can be foreseen, since it is known from [10] that k-bounded places in P/T Petri nets can be associated with k-length buffers in Dataflow domain. In a similar way, with T-Invariants one can preview the initial markings, M 0 for each place in P/T domain (arc in Dataflow domain). For a further reading about this mapping please refer to [10]. The development and simulation of the resulting Petri nets equivalent models was performed by two non commercial tools that are available freely in the web: (1) Signal/Net system analyzer SESA [1], a non graphical Petri net editor; (2) Still TINA - TIme Petri Net Analyzer [2], a graphical editor with a simulator to perform a Petri net step by step animation. The invariant analysis (used in Section 3) was performed in both environments.

Figure 3
figure 3

Translation mapping diagram (adapted from [12]).

Full size image

3 Results and Discussion

The results presented by Govindarajan et al. shows several discrepancies about storage requirements. In page 221, the Fig. 2 represent a Synchronous Dataflow the algorithm concerning a Spectrum Analyzer. Starting on page 211, Section 2.3., second line is stated that “Next we compute the buffer requirement for each arc of the RSFG using an operational model. In this method we compute ...”, but one does not know effectively how these results are achieved, since the meaning of “operational model” is too broad and vague. One may disagree with what authors say in page 212, line 4 about “Since the prologue is executed only once, separate buffer allocation can be done for it.” This strategy is time consuming as well as buffer inefficient, since a well behaved dataflow can be planned if one can know in advance at the prologue the optimal initial number of tokens on the arcs which can also accommodate the repetitive pattern of the schedule. Using our methodology on Fig. 2. we obtain a new model on the Petri net side domain depicted on Fig. 4. Likewise for Fig. 2. in [7], page 210, proceeding the same way as before, we can also reach a Petri net model of the corresponding RSFG example (refer to Fig. 1). Since each Petri net is composed by a set of places and transitions one can define a matrix, which is usually called incidence, C, of dimension m×n, with m places and n transitions. The entries of this matrix expresses the token balance associated to the firing of each transition. Once in this domain our focus is on the structural analysis, mainly the properties that remain constant during the execution of the PN. In this context, P-Invariants identifies a group of places where the weighted token sum remains constant for any new marking, thereby establishing region(s) where the allocation of resources does not grow endlessly, insofar with T-Invariants a group of transitions may fire that it does not affect the new marking on the Petri net. This way T-Invariants show their adequacy in the identification of cyclical properties of a Petri net. Using these P-Invariants, v, in the fundamental equation (also known as state equation, since it is possible to predict a new state resulting from a firing sequence vector f),

$$ M (p_{i}) = M_{0} (p_{i}) + C \cdot f $$
(1)

with C being the incidence matrix, M(p i ) the actual marking after a firing sequence, and M 0(p i ) the initial marking associated to each place p i , where we pre-multiply it by v T,

$$ v^{T} \cdot M (p_{i}) = v^{T} \cdot M_{0}(p_{i}) + v^{T} \cdot C \cdot f $$
(2)

If there exists a v∈Z n such that v≠0, then v is a P-Invariant of Eq. 2 if and only if the right most part is null,

$$ v^{T}\cdot C = 0 $$
(3)
Figure 4
figure 4

Petri net place-transition equivalent model of spectrum analyzer.

Full size image

Considering Petri net model in Fig. 1, performing a P-Invariant analysis using the software tools SESA [1] and TINA [2] yields the following P-Invariant vectors:

$$ v=\{(1\ 1\ 0\ 0\ 0\ 0)^{T},(0\ 0\ 1\ 1\ 0\ 0)^{T},(0\ 0\ 0\ 0\ 1\ 1)^{T}\} $$
(4)

Based on Eq. 3, Eq. 2 reduces to

$$ v^{T}\cdot M(p_{i})= v^{T} \cdot M_{0}(p_{i}) $$
(5)

with i={0,1,...,5}, hence the corresponding P-Invariant equations are,

$$\begin{array}{@{}rcl@{}} M(p_{0}) + M(p_{1}) &=& 3 \end{array} $$
(6)
$$\begin{array}{@{}rcl@{}} M(p_{2}) + M(p_{3}) &=& 3 \end{array} $$
(7)
$$\begin{array}{@{}rcl@{}} M(p_{4}) + M(p_{5}) &=& 6 \end{array} $$
(8)

From the previous equations one can achieve the following maximum buffer requirements for each place in the PN model (and arc in the associated dataflow model),

$$\begin{array}{@{}rcl@{}} M(p_{0}) &=& M(p_{1}) = 3 \end{array} $$
(9)
$$\begin{array}{@{}rcl@{}} M(p_{2}) &=& M(p_{3}) = 3 \end{array} $$
(10)
$$\begin{array}{@{}rcl@{}} M(p_{4}) &=& M(p_{5}) = 6 \end{array} $$
(11)

Table 1 presents a summarized view of the memory buffer requirements per arc (place) reached by Govindarajan (first two rows) and (third and fourth row) using the proposed approach. So on page 212, second paragraph, line 3, the total maximum buffer size foreseen in that example of a RSFG is not correct as well as some values associated to a few arcs (refer to Table 1). Therefore instead of “... A buffer size of 2 is required for the arcs (a,b) and (b,d), and a buffer size of 3 is required for (b,a) and (d,b). Thus the total buffer requirement for the schedule of Table 1 is 22.” one should read “... A buffer size of 3 is required for the arcs (a,b), (b,a), (d,b) and (b,d). Thus the total buffer requirement for the schedule of Table 1 is 24.”.

Table 1 Buffer requirements for a schedule of RSFG example in [7], pag. 210.
Full size table

It is not clear how the buffer requirements for the schedule depicted in Fig. 2 and other signal processing models present by Govindarajan et al. [7] are achieved. We claim that with our methodology (as explained previously) applied to spectrum analyzer shown in Fig. 5 (c) of [7], page 221 by the aforementioned authors also present some incongruence at certain parts. The authors state that arc (e,a) in spectrum analyzer requires three (3) units, but using our approach one claims that this arc demands four (4) units, therefore the total buffer requirement for a schedule of spectrum analyzer will be seventeen (17) units instead of sixteen (16) units. Due to this misjudgment, one should also read on page 222, second column, line 8, “lastly arc (e,a) requires a buffer of size 4. Thus the total memory requirement for the given schedule, under buffer sharing, is only 9. Thus buffer sharing significantly reduces the buffer requirements from 17 to 9.” in place of “lastly arc (e,a) requires a buffer of size 3. Thus the total memory requirement for the given schedule, under buffer sharing, is only 8. Thus buffer sharing significantly reduces the buffer requirements from 16 to 8.’’

4 Conclusions

In this paper we point out misjudgments on the evaluation of buffer requirements based on a new framework supported by mathematical representation of Petri nets. This framework allows one to establish an inter-relation between a Dataflow and a Petri net with the help of a mapping between these two domains. This strategy has proved its reliability in several workout examples, and some signal processing applications during previous years (refer to [12, 13]).