Chapter 7 Dataflow Architecture

7.1 Dataflow Models  A dataflow program: the sequence of operations is not specified, but depends upon the need and availability of data. data driven  Dataflow concepts: the finest grain level (instruction level parallelism)  DFG (dataflow graph): Figure 7.2

7.1 Dataflow Models (continued)  Two dataflow models: based on firing rule Static dataflow model: Figure 7.3  A node fires only when each of its input arcs has a token and its output arcs are empty. Dynamic dataflow model: Figure 7.5  A node fires only when all its input have tokens and the absence of tokens on its outputs is not necessary.

7.2 Dataflow Graphs  DFG operators: Figure 7.6  DFG control operators: Figure 7.7  Race condition: To eliminate the problem  labels are attached to the data

7.3 Dataflow Languages  Id (Irvine dataflow language)  VAL (Value-oriented Algorithm Language)  HASAL  Lapse  SISAL (Streams and Iteration in Single Assignment Language)

7.3 Dataflow Languages (continued)  The essential features of dataflow language The language should be functional. The language should allow a nonsequential specifications The language should obey the single assignment rule. The language should be no side effects.

7.3 Dataflow Languages (continued) Differences of dataflow languages from conventional languages  The concepts of variables: all variables are values not memory locations  Applicative  Locality of effect  Go to constructs are not required  The iteration structures are somewhat unusual.

7.4 Example Systems  Static architectures MIT static architecture TI’s DDP system LAU  Dynamic architecture Manchester dataflow machine Irvine dataflow machine Demand-driven machine (DDM) Epsilon dataflow processor EDDY MIT/Motorola Monsoon system

7.5 Performance  Figure 7.19  Figure 7.21  Figure 7.22  Table 7.1  Table 7.2  Table 7.3