Solution
When using the LabVIEW FPGA module, care must be used when using local variables. Unlike a windows targeted LabVIEW VI, local variables can behave differently when implemented in LabVIEW FPGA, especially when working across different clock domains in single cycle timed loops (SCTL).
The following screenshot demonstrates a common mistake when transferring data across multiple clock domains. In a windows targeted VI, the local variables read in the lower loop during each iteration would always be in sync with each other because of software dataflow constraints that ensure that the data read in the lower while loop would always be the last value written to the local variable. However, in LabVIEW FPGA, there is hardware implementation of dataflow in the form of handshaking logic. Handshaking adds additional logic to your code to ensure that data is present to perform your operations. For example, in a multiply operation, two numeric inputs must be present before the multiply routine is executed. The hardware handshaking ensures that both inputs must be present in order to perform the multiply.
One consequence of hardware handshaking in this example is the delay due to the speed of the additional logic. In the VI shown above, a problem arises because the handshaking logic connected to each variable takes more than one clock cycle to execute, but the SCTL forces the code inside to execute in one clock cycle. This can result in "old" values being read in the lower loop due to the fact that the handshaking logic introduced a delay in the writing operation. To alleviate this problem, use a FIFO instead of a local variable to pass data between loops.
Another issue that arises in the example above is the possibility of the numeric and Boolean values not being synchronized to each other. This is due to the fact that there is no logic to ensure that the Boolean and numeric local variables are synchronized. To get around this, bundle the numeric and Boolean values and pass the cluster by local variable.
When working within the same clock domain, the synchronization issues described above do not apply. So, if both loops shown above were using the 10 MHz timing source, the synchronization issues would not occur.