LabVIEW FPGA Idea Exchange

Hi,

I find Conditional Disable Symbols in FPGA code very useful especially in a R&D environment where needs and code change back and forth rapidly. However, I also find it hard to keep track of all these changes. I propose to add support for reading FPGA Conditional Disable Symbols from Host to enable VIs like "Is_FPGA_Function_A_Enabled.vi" that would allow for the Host program to know the state (hardware revision of sorts) of the FPGA bitfile and adapt.

I'll give an example to illustrate this proposal.

Function A is implemented in FPGA bitfile v1. Function B is implemented in Host and is based on multiple calls to Function A. Your boss now wants Function B implemented in FPGA for performance reasons with means to disable the code if required. For this you define a Conditional Disable Symbol in the FPGA project "FPGA_WITH_FUNC_B" and write FPGA code for FPGA bitfile v2. Switching between v1 and v2 is easy enough from the project manager, but for the Host side there's no way of knowing whether Function B is implemented directly in the FPGA or should be "emulated" via Function A as before. If you could do a check like "if FPGA_WITH_FUNC_B == TRUE" you could easily make the Host aware of this.

Regards,

solarsd

View All (1)

Similar to the overflow-status-functionality (which I missused in the picture below) it would be useful to make it possible to include handshaking bit(s) in the signal as well. It is true that this could be implemented using a cluster. However the additional cluster-level will imply a multiplication of type definitions; moreover a built in handshaking-bit-functionality could be included directly in the high-speed math functions an registers, so that a seperate 'output valid' terminal would not be necessary.

When working with CLIP-generated clocks we need to have good UCF files for proper compilation control (Something we now have after WEEKS of debugging ).

At the moment the ucf files MUST be in Users\Public\Documents\National Instruments\FlexRIO\IOModules for the code to work even though all other CLIP-relevant files can be located anywhere.

Please let us use the ucf file located int he same directory as the CLIP we're using otherwise we'll end up with cross-linking nightmares between users who don't have the right version in their local folder.

Shane

The "FPGA I/O Properties" that can be set for an I/O point under an FPGA target consist of just the name for the I/O point.

On the other hand, the "Shared Variable Properties" that can be set for a similar I/O point under a cRIO chassis are much more extensive and include a description field.

I'd like to see a similar description field included/available for the FPGA I/O points. As it is information that is maintained as part of the "project", the reduced functionality normally associated with an FPGA should not be an issue.

As long as I'm wishing, it would also be nice to be able to export/import names/descriptions/properties from something akin to the "Multiple Variable Editor" for both "FPGA I/O Properties" and "Shared Variable Properties" and if an I/O module is moved from the FPGA level to the cRIO level or vice versa, allow us to transfer or import the relevant properties from one level to the other.