Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
language:langs:dflow [2023/01/08 18:38]
rajit [Split]
language:langs:dflow [2024/01/07 11:24] (current)
rajit [Clusters and Ordering]
Line 51: Line 51:
 </code> </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.+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 ? 1 : 0} A -> X, Y 
 +
 +</code> 
 + 
 +Instead, use the following: 
 +<code  act> 
 +dataflow { 
 + c = 0 ? 1 : 0 -> ctrl; 
 +{ctrl} A -> X, Y 
 +
 +</code>
 ===== Controlled merge ===== ===== Controlled merge =====
  
Line 66: Line 82:
 } }
 </code> </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 ===== ===== Implicit copy and explicit buffers =====
  
Line 121: Line 137:
 </code> </code>
 For each output generated, the control channel ''c'' will produce a 0 or 1 token depending on the choice made by the arbiter. 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 ===== ===== Sink =====
  
Line 174: Line 196:
 </code> </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>