Differences

This shows you the differences between two versions of the page.

--- language:langs:dflow [2022/05/13 12:50] – rajit
+++ language:langs:dflow [2024/07/22 17:54] (current) – [Function] rajit
@@ Line 26: / Line 26: @@
 ===== Function =====
-The syntax shown above corresponds to the //function// dataflow block. A function dataflow element receives one input token on each of its input channels, computes a function of the values received, and produces one output token with the value computed. The example above shows the function syntax. The left hand side of the arrow is a channel expression that corresponds to the function being computed, and the right hand side is the name of the channel on which the output is produced.
+The syntax shown in the first example above corresponds to the //function// dataflow block. A function dataflow element receives one input token on each of its input channels, computes a function of the values received, and produces one output token with the value computed. The example above shows the function syntax. The left hand side of the arrow is a channel expression that corresponds to the function being computed, and the right hand side is the name of the channel on which the output is produced.
 ===== Split =====
@@ Line 51: / Line 51: @@
 </code>
+The bit-width of channel ''c'' should be at most the number of bits needed to specify the number of outputs. If the value of the token on ''c'' is not within the range ''0'' to ''n'' (for ''n+1'' channels on the right hand side), then the dataflow component can fail in an unspecified manner. Furthermore, the bit-widths of all the data channels  (''I'', ''O0'', etc above) must be the same.
+The control channel, input data, and output data can only be channels. If a control expression is needed, one must use a combination of a split as well as a function. For example, if a split takes an input from ''A'' and sends it to ''X'' if ''c=0'' and ''Y'' otherwise, then the following is a syntax error:
+<code act>
+dataflow {
+  {c = 0 ? 0 : 1} A -> X, Y
+}
+</code>
+Instead, use the following:
+<code  act>
+dataflow {
+ c = 0 ? 0 : 1 -> ctrl;
+{ctrl} A -> X, Y
+}
+</code>
 ===== Controlled merge =====
@@ Line 65: / Line 82: @@
 }
 </code>
+The bit-width of ''c'' has analogous constraints as in the case of a split, and it also has similar syntax restrictions.
 ===== Implicit copy and explicit buffers =====
@@ Line 75: / Line 92: @@
 }
 </code>
-The fact that ''a'' is used twice on the left hand side implies that there will be a token copy circuit introduced. Note also that semicolon is used as a separator, like in the CHP language.
+The fact that ''a'' is used twice on the left hand side implies that there will be a token copy circuit introduced. Note also that semicolon is used as a separator, so there is no semicolon after the last dataflow statement in the block.
 In pipelined circuits, it is important to be able to introduce slack to optimize performance. The syntax for this is the following:
@@ Line 120: / Line 137: @@
 </code>
 For each output generated, the control channel ''c'' will produce a 0 or 1 token depending on the choice made by the arbiter.
+This syntax is also supported for the deterministic merge.
+<code act>
+dataflow {
+ {*} I0, I1 -> O, c
+}
+</code>
+In both these cases, the control output channel must have the exact bitwidth needed to specify which input token was routed to the output.
 ===== Sink =====
@@ Line 173: / Line 196: @@
 </code>
+Dataflow clusters are hints to the implementation that these dataflow elements should be grouped together---for example, by having a single control that is shared by all the elements of the cluster.
+Finally, consider the following dataflow example:
+<code act>
+dataflow {
+    a + b -> c; // produce an output on channel c
+    d + e -> out  // sum d and e and produce the output on out
+ }
+</code>
+Furthermore, suppose that the ''c'' output is passed to another process where it is transformed to a new value, and it is this new value that is provided on channel ''e'' that is part of this dataflow block.
+When optimizing the dataflow block, one may decide to group the control for the two dataflow elements. However, doing so would result in deadlock, because the combined dataflow block would wait for inputs to arrive on ''a'', ''b'', ''d'', and ''e''  //before producing an output on ''c''//. It is not possible to determine that ''e'' in fact depends on ''c'' without a full analysis of the entire ACT program.
+To simplify optimizations, the dataflow language also supports the ''order'' directive as the first item in the dataflow block. The same example above would be specified:
+<code act>
+dataflow {
+  order {
+     c < e    // c must be produced before e is available
+   }
+   a + b -> c;
+   d + e -> out
+ }
+</code>
+In general, the order block contains a semi-colon separated list of directives. Each directive is a list of comma-separated channels followed by ''<'' followed by a second comma-separated list of channels. The directive means that all the channels in the first group must produce outputs before any of the channels in the second group can receive inputs.
+====== Syntactic replication ======
+The dataflow sub-language has support for syntactic replication for splits, merges, mixers, and arbiters. For a split, the output side can use syntactic replication; for the others, the input side can use syntactic replication.
+For example, the following syntax is legal (assuming everything is of the right type):
+<code act>
+dataflow {
+  {ctrl} l -> (, i : 8 : out[i])
+ }
+</code>