Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
language:langs:dflow [2024/07/22 17:53] – [Implicit copy and explicit buffers] rajitlanguage:langs:dflow [2026/05/13 10:58] (current) – [Function] rajit
Line 16: Line 16:
 The dataflow language has the following primitives: The dataflow language has the following primitives:
   * Function: reads tokens on all of its inputs, computes some function of those inputs, and produces an output token in response;   * Function: reads tokens on all of its inputs, computes some function of those inputs, and produces an output token in response;
-  * Split: conditionally routes an input token to one of its outputs; +  * Split (a.k.a. demux): conditionally routes an input token to one of its outputs; 
-  * Controlled merge (a.k.a. merge): conditionally reads one of its input tokens and routes it to its output; +  * Controlled merge (a.k.a. mux): conditionally reads one of its input tokens and routes it to its output; 
-  * Deterministic mergeassumes input token arrivals are mutually exclusive, and sends the input token to its output; +  * Mergethis component waits for the arrival of an input token on any one of its inputs, and sends the arriving input token to the output. Merges come in two flavors: 
-  * Non-deterministic merge: same thing as deterministic merge, except input tokens are not assumed to be mutually exclusive.+     * Deterministic merge: assumes input token arrivals are mutually exclusive 
 +    * Non-deterministic merge: input tokens are not assumed to be mutually exclusive, and are selected in any (non-deterministic) order
   * Initial tokens: these are specified directly in the syntax   * Initial tokens: these are specified directly in the syntax
-  * Copy: implicit, with the same channel is used for multiple inputs+  * Copy (a.k.a. fork): implicit, with the same channel is used for multiple inputs
   * Sources and sinks have short-hand syntax.   * Sources and sinks have short-hand syntax.
  
 ===== Function ===== ===== 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 =====+By default, a function implicitly contains a buffer. However, functions can also have additional buffering on their output. The syntax used for this purpose is shown below. 
 +<code act> 
 +dataflow { 
 +   a + b -> [2] c 
 +
 +</code> 
 +In this example, one extra buffer stage is added to the output of ''c''. This can be viewed as syntactic short-hand for the following: 
 +<code act> 
 +dataflow { 
 + a + b -> c1; 
 + c1 -> c 
 +
 +</code> 
 +The ''2'' specifies that we want to use two stages for this function block, which is the same as introducing one extra buffer on the output. (This is useful for manual slack matching for performance.) The explicit buffer introduced is sometimes referred to as a dataflow latch in the literature. 
 + 
 + 
 +===== Split or Demux =====
  
 The //split// dataflow element receives a control token and a data token, and uses the value of the control token to route the data token to one of the output channels. If the control token=0, the first channel is used; if it is 1, then the next  channel is used; etc. The syntax for this is shown below: The //split// dataflow element receives a control token and a data token, and uses the value of the control token to route the data token to one of the output channels. If the control token=0, the first channel is used; if it is 1, then the next  channel is used; etc. The syntax for this is shown below:
Line 68: Line 85:
 } }
 </code> </code>
-===== Controlled merge =====+===== Controlled merge or Mux =====
  
 The //controlled merge// dataflow element receives a control token, and then uses the token determine which input channel should be used to accept an input data token. This data token is routed to the output. The syntax is: The //controlled merge// dataflow element receives a control token, and then uses the token determine which input channel should be used to accept an input data token. This data token is routed to the output. The syntax is: