| |||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
| Description | |||||||||||||||||
The dataflow library defines data types, process constructors and functions to model dataflow process networks, as described by Lee and Parks in Dataflow process networks, IEEE Proceedings, 1995 ([LeeParks95]). Each process is defined by a set of firing rules and corresponding actions. A process fires, if the incoming signals match a firing rule. Then the process consumes the matched tokens and executes the action corresponding to the firing rule. | |||||||||||||||||
| Synopsis | |||||||||||||||||
| |||||||||||||||||
| Data Types | |||||||||||||||||
The data type FiringToken defines the data type for tokens. The constructor Wild constructs a token wildcard, the constructor Value a constructs a token with value a. A sequence (pattern) matches a signal, if the sequence is a prefix of the signal. The following list illustrates the firing rules:
| |||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
| Combinational Process Constructors | |||||||||||||||||
Combinatorial processes do not have an internal state. This means, that the output signal only depends on the input signals. To illustrate the concept of data flow processes, we create a process that selects tokens from two inputs according to a control signal. The process has the following firing rules [LeeParks95]:
The corresponding ForSyDe formulation of the firing rules is:
selectRules = [ ([Wild], [], [Value True]),
([], [Wild], [Value False]) ]
For the output we formulate the following set of output functions: selectOutput xs ys _ = [ [headS xs], [headS ys] ] The select process selectDF is then defined by:
selectDF :: Eq a => Signal a -> Signal a
-> Signal Bool -> Signal a
selectDF = zipWith3DF selectRules selectOutput
Given the signals s1, s2 and s3 s1 = signal [1,2,3,4,5,6] s2 = signal [7,8,9,10,11,12] s3 = signal [True, True, False, False, True, True] the executed process gives the following results:
DataflowLib> selectDF s1 s2 s3
{1,2,7,8,3,4} :: Signal Integer
The library contains the following combinational process constructors: | |||||||||||||||||
| |||||||||||||||||
| The process constructor mapDF takes a list of firing rules, a list of corresponding output functions and generates a data flow process with one input and one output signal. | |||||||||||||||||
| |||||||||||||||||
| The process constructors zipWithDF takes a list of firing rules, a list of corresponding output functions to generate a data flow process with two input signals and one output signal. | |||||||||||||||||
| |||||||||||||||||
| The process constructors zipWith3DF takes a list of firing rules, a list of corresponding output functions to generate a data flow process with three input signals and one output signal. | |||||||||||||||||
| Sequential Process Constructors | |||||||||||||||||
Sequential processes have an internal state. This means, that the output signal may depend internal state and on the input signal. As an example we can view a process calculating the running sum of the input tokens. It has only one firing rule, which is illustrated below.
Firing Rule Next State Output
------------------------------------
(*,[*]) state + x {state}
A dataflow process using these firing rules and the initial state 0 can be formulated in ForSyDe as
rs xs = mealyDF firingRule nextState output initState xs
where
firingRule = [(Wild, [Wild])]
nextState state xs = [(state + headS xs)]
output state _ = [[state]]
initState = 0
Execution of the process gives
DataflowLib> rs (signal[1,2,3,4,5,6])
{0,1,3,6,10,15} :: Signal Integer
Another 'running sum' process rs2 takes two tokens, pushes them into a queue of five elements and calculates the sum as output.
rs2 = mealyDF fs ns o init
where
init = [0,0,0,0,0]
fs = [(Wild, ([Wild, Wild]))]
ns state xs = [drop 2 state ++ fromSignal (takeS 2 xs)]
o state _ = [[(sum state)]]
Execution of the process gives
DataflowLib>rs2 (signal [1,2,3,4,5,6,7,8,9,10])
{0,3,10,20,30} :: Signal Integer
| |||||||||||||||||
| |||||||||||||||||
| The process constructor scanlDF implements a finite state machine without output decoder in the ForSyDe methodology. It takes a set of firing rules and a set of corresponding next state functions as arguments. A firing rule is a tuple. The first value is a pattern for the state, the second value corresponds to an input pattern. When a pattern matches, the process fires, the corresponding next state is executed, and the tokens matching the pattern are consumed. | |||||||||||||||||
| |||||||||||||||||
| The process constructor mooreDF implements a Moore finite state machine in the ForSyDe methodology. It takes a set of firing rules, a set of corresponding next state functions and a set of output functions as argument. A firing rule is a tuple. The first value is a pattern for the state, the second value corresponds to an input pattern. When a pattern matches, the process fires, the corresponding next state and output functions are executed, and the tokens matching the pattern are consumed. | |||||||||||||||||
| |||||||||||||||||
| The process constructor mealyDF implements the most general state machine in the ForSyDe methodology. It takes a set of firing rules, a set of corresponding next state functions and a set of output functions as argument. A firing rule is a tuple. The first value is a pattern for the state, the second value corresponds to an input pattern. When a pattern matches, the process fires, the corresponding next state and output functions are executed, and the tokens matching the pattern are consumed. | |||||||||||||||||
| Produced by Haddock version 2.6.1 |