NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
This document contains the LabVIEW 2010 FPGA Module known issues that were discovered before and since the release of LabVIEW 2010 FPGA Module. Not every issue known to NI will appear on this list; it is intended to only show the severe and more common issues that can be encountered.
The LabVIEW 2010 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
National Instruments is committed to maintaining compatibility with Microsoft Windows technology changes. However, NI has become aware of a number of issues of potential significance regarding Microsoft Windows 7. To learn how Windows 7 affects your use of NI products, visit ni.com/info and enter the Info Code windows7.
The following items are known issues in LabVIEW FPGA 2010 Module sorted by Category.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| Building and Distributing LabVIEW Applications | ||||||
| 93395 4GIHITXE Return | Modifying conditional disable symbols requires recompile If you modify the conditional disable symbols in a project, the FPGA Module requires you to recompile the FPGA VI even if the FPGA VI does not use Conditional Disable structures. Workaround: Recompile the FPGA VI.
| |||||
| 98807 Return | Host VI does not get notified of changes when building an application If you make changes to an FPGA VI without saving the host VI, the host VI refers to the old FPGA VI when you build an application. Workaround: You must open and save the host VI before building an application.
| |||||
| 247993 Return | Removing a C-Series Module in a Project Forces Recompilation Removing a module from a Chassis in a LabVIEW FPGA Project will force a recompilation, even if all VIs in the Build Specification's hierarchy do not reference the module. Workaround: NA
| |||||
| 354689 Return | Customer designs may fail with an over-mapping error if Output data and enable are synchronous to different clocks Users can place Output Data and Enable nodes in different clock domains. This results in a Tri-state buffer on the FPGA that is enabled by a signal in the different clock domain than the data signal. Some FPGA families may not support this configuration, and user's design may fail to compile with an over-mapping error in some situations. For a Virtex 2 compile, the error may look similar to the attached Compilation Error.png file. The situation where it might fail for Virtex 2 is when two IO Nodes are mapped over two adjacent IOBs and the Data and Enable flops for the IOs are synchronous to 3 or more different clocks. Workaround: The workaround is to modify the VI. Move the Output Enable node into the same clock domain as the Output Data node.
| |||||
| External Code | ||||||
| 283866 Return | Namespace conflicts for constants declared in packages for IP There is a known issue regarding namespace conflicts for constants declared in packages on Virtex 2 targets. See Xilinx Answer Record 34751 for more details: http://www.xilinx.com/support/answers/34751.htm Workaround: Create unique names for all constants in packages in order to avoid namespace collisions between constants declared in other packages. Avoid naming constants beginning with 'k*" to avoid namespace collisions between user code and National Instruments code.
| |||||
| 238241 Return | When entity level attributes are used in a VHDL file, IP Integration Node wizard hangs on the second dialog page. When entity level attributes are used in a VHDL file, IP Integration Node wizard hangs on the second dialog page. Workaround: The wizard only extracts information from the top-level VHDL file, so add another VHDL wrapper that instantiates the original wrapper. In the new wrapper, do not mention the entity attribute.
| |||||
| 283397 Return | All CLIP vhd files must have a lowercase vhd extension. CLIP vhd files are required to have a lower case extension or there will be an odd behavior during compiles. Workaround: Define the VHD files with a lower case extension in the clip XML file.
| |||||
| 297138 Return | The length of the port name in the top-level VHDL file of a CLIP should not exceed 22 letters. The length of the port name in the top-level VHDL file of a CLIP should not exceed 22 letters. Or else, the long name will be truncated by LabVIEW FPGA, which will lead to compilation failure. Workaround: Change the port name to be shorter than 22 letters.
| |||||
| Functions, VIs, and Express VIs | ||||||
| 150867 Return | "Not supported for current target" message may occur when Preallocate Arrays is not set. The "Not supported for current target" error may be displayed for FPGA Analysis functions when the FPGA Preallocate Arrays option is not set. The actual error is that this option must be selected. Workaround: In VI Properties check the Preallocate Arrays option.
| |||||
| 151047 Return | High-Throughput Math Library node fails to compile if pipeline stage exceeds 64 If the number of pipeline stages exceeds 64, the compile will report "Loop has iterated 64 times. Use "set -loop_iteration_limit XX" to iterate more." This usually happens in configurations of high-throughput math library nodes where the output data width is 64 and throughput is 1 cycle/sample inside SCTL. Workaround: Reduce the pipeline stages by reducing the output word length or the throughput. If more than 64 pipeline stages are needed, please contact National Instruments support.
| |||||
| 217824 Return | FIFOs with built-in control are not supported with cycle-accurate simulation. When attempting to use full diagram simulation on a design using FIFOs with built-in control logic, there is no simulation model for these elements. Workaround: Use a conditional disable structure around the built-in FIFOs when using full diagram simulation.
| |||||
| 232504 Return | Compilation on Spartan-6 FPGAs fails when compound add is placed before Loop Condition terminal. Compilations for Spartan-6 targets can fail is a compound add function is placed directly before the Loop Condition terminal in a single-cycle timed loop. Workaround: Change number of inputs to compound add to an even number or replace with regular add functions.
| |||||
| 233916 Return | Username that contains 2-byte characters might result in incorrect behaviors for CLIP and IP Integration The issue is that if username of the operation system contains some 2-byte characters such as some Japanese characters, the wizard dialog of CLIP or IP Integration Node might encounter the following errors when user performs syntax check or simulation model generation: Error Code -61499 at niFpgaIPINodeGetDllError.vi:1 Workaround: To work around this issue, the user should create or switch to another username that doesn't contain 2-byte characters such as English username.
| |||||
| 246665 Return | Start invoke method is allowed for non-existent DMA FIFO. When renaming a FIFO in a project, the Start method in the host VI will not break the run arrow although it is still configured for the FIFO that no longer exists. This can cause an overflow error as soon as the application starts. Workaround: Reconfigure the Start method to use the updated FIFO.
| |||||
| LabVIEW Project | ||||||
| 223670 Return | Compiling a VI in one FPGA context creates a code generation error if the VI is open and broken in another FPGA context. The compilation of a VI may return an error saying the VI is broken if the same VI is open and broken in another FPGA context. The error occurs at the beginning of stage 1 of the compilation. Workaround: Close the broken copies of the VI in the other FPGA contexts.
| |||||
| 233957 Return | Error -61071: DMA FIFO not found or out of sync with bitfile. You may obtain the following error when using the host interface DMA methods: Error -61071 LabVIEW FPGA: The selected DMA FIFO was not found or is out of sync with the bitfile. This error may sometimes occur when the DMA FIFO is renamed in the project. The name of the FIFO in the host VI method will correctly match the name of the FIFO project item, but the DMA FIFO in the FPGA VI did not update correctly. For example, I have a FIFO in my project, FPGA VI, and host VI named "FIFO A". I rename the project item to "FIFO B". The project item and host VI update correctly, but the FPGA VI still refers to "FIFO A" and compiles without error. Then, you will get error -61071 when you attempt to use the FIFO from that bitfile. Workaround: Reconfigure the FIFO nodes in the FPGA VI for the updated FIFO name and recompile.
| |||||
| 277539 Return | FPGA VI remains running on the target while the VI is open in edit mode. While the top-level FPGA VI is running, you can open a reentrant subVI from the block diagram and change to edit-mode from the clone. If you break the subVI in edit-mode, the top-level FPGA VI will also break, but the VI will remain running on the target. If you fix the subVI, both VIs will no longer be broken and the FPGA VI cannot be stopped. Workaround: Reboot the target.
| |||||
| Miscellaneous | ||||||
| 224914 Return | Error -61499 when opening Memory Properties Dialog Box or FIFO Properties Dialog Box in previous versions of LabVIEW FPGA for items with a data type from custom control If a Memory item or FIFO item is configured with a data type from a custom control in LabVIEW FPGA 2010 and then save for a previous version of LabVIEW FPGA, an internal error dialog will appear when opening the Memory Properties Dialog Box or FIFO Properties Dialog Box for that item in the previous version of LabVIEW FPGA. FIFO and Memory data types from custom controls are not supported in previous versions of LabVIEW FPGA. Workaround: Dismiss the internal error dialog. Click Cancel on the Memory Properties Dialog Box or FIFO Properties Dialog Box. Delete the Memory or FIFO item from the project.
| |||||
| 228782 Return | Without proper .NET framework CompileWorker will crash/fail If installed normally there should be no problem. If the user uninstalls the .Net 3.5 framework and has no .Net framework on their machine then the compile worker will crash on launch with a strange error. (I don't currently have access to a computer to reproduce what it looks like but it says nothing about a lack of .Net being the culprit.) If the user uninstalls the .Net 3.5 framework and has an older version of the .Net framework then the worker will likely return a meaningful error about needing a newer version of .Net. Workaround: Install the .Net 3.5 framework.
| |||||
| 234568 Return | Compilation fails with NI-Farm: Invalid username and password combination error When compiling on a remote machine, if client computer goes into hibernation (sleep), the compilation will fail when the client computer wakes up. The error returned is NI-Farm: Invalid username and password combination error when called by Get Status. If the computer goes into hibernation when compiling locally, the error will be "The compile worker terminated this compilation unexpectedly, and there were no other compile workers available to restart this compilation." Workaround: Disconnect from the compilation before going into hibernation. In the Compilation Status dialog, right-click the build specification and choose 'Disconnect', or click the arrow next to the 'Close' button and choose 'Disconnect All'. This will resolve the remote compile error. Note: There is no workearound for local compile machine going into hibernation.
| |||||
| 235225 Return | Download procedure may not work as expected in simulation When using the download FPGA Inteface method from a host VI, LabVIEW loads the bitstream to the FPGA which will reset the entire FPGA. In simulation, the downlaod procedure calls the reset procedure which will not reset or reinitialize the following: * contents of memory blocks * feedback registers configured to ignore reset Workaround: Avoid calling the download procedure programmatically except at the beginning of simulation, especially if your code relies on the download procedure to reinitialize or reset the components mentioned above.
| |||||
| 252874 Return | Feedback cycle wired to global write fails to compile Feedback cycle wired to global write fails to compile Workaround: Replace the feedback node with a shift register
| |||||
| 197816 Return | Virtex 6 design with PLLs simulation run forever Currently there is not a mechanism to stop the Virtex 6 PLL from running, which can cause the simulation to continue running when the "Run All" command is used in the simulator. Workaround: You can use one of the following options to stop the simulation: * Add an assertion failure to the of end your test bench. * Run the test bench for a specified amount of time.
| |||||
| Upgrade - Migration | ||||||
| 162027 4HG9BGP2 Return | Control VIs from 8.5.x and earlier do not automatically migrate to the FPGA Module 2009 implementation of the Control VIs Control VIs from 8.5.x and earlier will work with LabVIEW 2009. However, if you replace these legacy VIs with the current version of these VIs, you might need to adjust terminal names, single-cycle Timed Loop support, and fixed-point support. Workaround: NA
| |||||
| 257184 Return | Upgrading with clocks from CLIP can change the configured clocks. When upgrading, if a design uses CLIP clocks, the configuration of these clocks may be reset. Workaround: Reconfigure the CLIP clocks in the project.
| |||||
| 276311 Return | Upgrading from LabVIEW FPGA 2009 may cause designs using DSP48E components to overmap. When upgrading from LabVIEW FPGA 2009, it is possible that designs that fit on the FPGA target previously will fail to compile due to overmapping of DSP48E components. This is due to a change in the Xilinx compile process from version 10.1 to 11.x and later. Workaround: Use High-Throughput multiplies configured to use Look-Up Tables to reduce the number of DSP48Es used for multiplication functions.
| |||||
Document last updated on 2/6/2013