Clock-Driven Loops force nodes to return data every clock cycle. However, some nodes, called multi-cycle nodes, need more than one cycle to compute a valid result. Therefore, nodes that depend on data from multi-cycle nodes must know whether that data is valid. Use a handshaking protocol so that nodes in a Clock-Driven Loop communicate with one another to verify that transferred data is valid every clock cycle.
Create the following diagram to ensure that nodes within a Clock-Driven Loop send and receive only valid data through each loop iteration.
|Use a Data Exchange node or a terminal to connect the code in the Clock-Driven Loop to the rest of the system. Read FIFO in this diagram receives an array of data from a host VI and sends each sample sequentially to the downstream nodes in this code.|
Use nodes from the Clock-Driven Logic palette to process the input data. All multi-cycle nodes from the Clock-Driven Logic palette have one or more of the following handshaking inputs or outputs: input valid, output valid, ready for input, and ready for output.
For all multi-cycle nodes, wire output valid of the upstream node to input valid of the downstream node, and wire ready for output of the downstream node through a Feedback Node to ready for input of the upstream node.
|Use a Data Exchange node or a terminal to connect the code in the Clock-Driven Loop to the rest of the system. Write FIFO in this diagram transfers the data that is processed by the Clock-Driven Loop back to the Host VI in the order that the data is received.|
|Connect output valid of the upstream node with input valid of the downstream node to prevent the downstream node from accepting a new input until the upstream node produces a new valid result. When output valid is False, any data output from the node is undefined. The undefined value generated by a node may differ between simulation and hardware.|
to enable downstream nodes to communicate their readiness to receive a new input with upstream nodes. The
sends the result from
ready for input
ready for output
of an upstream node.
To avoid consuming an invalid input, each downstream node rejects new input data until both its ready for input produces a True value and its input valid receives a True value. Also, the upstream node sends new data only after the downstream node is ready for a new input, so the downstream node does not skip valid data.