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:
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.
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.