DSPOOM as a Graphical Model of Computation

As we have seen DSPOOM offers a completely object-oriented metamodel for digital signal processing. Nevertheless, the consequence of applying object-oriented modeling techniques to the signal domain not surprisingly yields a Graphical Model of Computation.

We will now compare DSPOOM graphical model to those introduced in section 1.5. In order to do so we will first summarize the main properties of its graphical model:

1. In the DSPOOM graphical MoC the main nodes in the graph correspond to Processing objects.
2. By connecting Ports from different Processing objects we are defining the arcs in the graphical model.
3. These arcs in the graph are interpreted as unbounded FIFO queues where data tokens are written and read.
4. Processing objects produce/consume from the FIFO queues in a synchronous manner, when told to do so by the flow control entity.
5. The data consumption/production rate of Processing objects is not fixed
6. This consumption rate may vary at run time.
7. By connecting controls from different Processing objects we are also defining a secondary set of arcs.
8. Controls are transmitted using an event-driven mechanism as soon as they are generated.
9. Controls are not enqueued and they overwrite past values even if they have not been read.

The first four properties in the list simply confirm the fact that DSPOOM's graphical MoC is appropriate for signal processing as those properties are shared by most existing graphical models that have been used in this domain.

The fact that Processing objects can produce/consume different quantities of data tokens leads us to observe that our model can be more easily assimilated to Dataflow Networks (see 1.5.1). The ``firing rules'' of Dataflow Networks are translated into region sizes in the DSPOOM models. The quantity of data tokens to be produced or consumed by a Processing object Port is specified by giving its region a particular size. This is precisely what Dataflow Networks firing rules usually specify.

But common Dataflow Networks such as Synchronous Dataflow Networks have firing rules that are statically defined (see 1.5.1). In order to have regions resizeable at run-time like those found in DSPOOM we have to turn to Dynamic Dataflow Networks (see section 1.5.1).

Note though, that the DSPOOM metamodel does not require all modeled applications to have dynamically resizeable regions. That is why a DSPOOM compliant model can be also assimilated to a Synchronous Dataflow Network. Therefore, whether a DSPOOM model can be statically scheduled or not is not a fundamental issue. As for the general case we will ensure that scheduling can be dynamically performed. But in many applications, and under some usually acceptable restrictions, static scheduling can be performed.

As a first conclusion, by looking at the first six properties and taking into account the previous discussion we may conclude that DSPOOM's graphical MoC is a:

``(possibly Dynamic) Dataflow Network''

But the control mechanism in DSPOOM introduces some differences. Its event-driven syntax introduces an extension to the basic Process Network and Dataflow language. This extension though is almost identical to that in Context-aware Process Networks (see section 1.5.1). The asynchronous coordination introduced in that model in order to be able to use context information to control KPN execution has the same requirements and features than DSPOOM's control mechanism. The interpretation given to controls in DSPOOM is slightly different as controls are seen as events directly travelling from Processing object to Processing object, without the need of an intermediate register such as the one deployed in Context-aware Process Networks. But then again, these are only implementation details as the basic and fundamental behavior, illustrated by our properties 7 to 9, are fully compatible.

Because of all this, we can say that DSPOOM's graphical model of computation is equivalent to a:

``Context-aware (and possibly Dynamic) Dataflow Network''

Note that until now we have consciously not mentioned the Data Node issue exposed in section 4.1.3. We consider that issue as an implementation detail as far as DSPOOM's graphical MoC is concerned. Anyway, it is interesting to discuss how this affects the basic graphical model.

DSPOOM's Data Node introduces a variant on the basic graphical MoC adding a secondary node type. In this layer, nodes in the graph can be either Processing Nodes or Data Nodes.

Figure 4.10: DSPOOM Data Node

Because the benefits and applications of making this issue explicit in DSPOOM's graphical MoC are not sufficiently clear we have chosen not to base the model on its existence. Nevertheless it is interesting to note, as a pointer for future work, that its inclusion makes our graphical model resemble a Petri Net and particularly an Object-Oriented Petri Net (see section 1.5.1), where Data Nodes are places and Processing objects are transitions.