Re: FPGA: Avoiding Feedback Node around a synchronous block in SCTL?

David is correct in that we don't allow this because it breaks our structured dataflow syntax. We would have to create some kind of execption to allow for this in FPGA diagrams, but this presents complications for code which might be used on both the host and FPGA (e.g. host simulation of an FPGA block).

LabVIEW does know your block is synchronous to a given clock - that is actually a property of the LabVIEW FPGA diagram. This is purely a reflection of our desire to deliver a consistent dataflow syntax across targets (Windows, RT, FPGA, etc.).

For this counter example, our recommendation would of course be to include this feedback node as part of the subVI logic. In practice, for me this is generally not an issue. The one instance where it does often arise is flow control of multi-rate blocks, in particular when using our "4-wire" protocol, where this feedback node can delay the propagation of back-pressure to upstream blocks. But even this can generally be addressed by a small about of buffer logic to filter out potential "lock-up" conditions where two or more blocks might have non-friendly behavior in terms of when they are and aren't ready for data or producing data. The real rub lies when going between Xilinx or HDL blocks and LabVIEW blocks, where such handshaking signals do not have this behavior. Generally, a 1-deep FIFO on the input to the HDL block can help to allieviate this, effectively "re-trying" input data from an upstream LabVIEW block, on cycles when the Xilinx / HDL block indicated that it wasn't ready for data (but the upstream LabVIEW block could not be aware of this because of the one-cycle delay of the feedback node). Here is an example of that logic:

Untitled.png

Hope this helps,

Ryan

Ryan Verret
Product Marketing Engineer
Signal Generators
National Instruments
(2,863 Views)