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 2012 and 2012 SP1 FPGA Module known issues that were discovered before and since the release of LabVIEW 2012 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 2012 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
The following items are known issues in LabVIEW FPGA 2012 and 2012 SP1 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.
| |||||
| 355167 Return | FPGA Compile Worker Will Throw Nondescript Error When an Out of Memory Exception Occurs A compile may return Error -61330: "An internal software error in the compile worker has occurred." if the worker runs out of available memory. Workaround: Use a compile worker with more available RAM.
| |||||
| 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.
| |||||
| 382264 Return | Build error occurs when building RT exe with FPGA bitfile containing multibyte character in its path Build error occurs when building RT exe with FPGA bitfile containing multibyte character in its path Workaround: Change the name of the FPGA target to English only
| |||||
| Compatibility | ||||||
| 356602 Return | Typedefs on FPGA front panels with non-Latin character filenames fail to be found when using the FPGA Read/Write Node When programming using the FPGA Interface configured statically to use an FPGA VI containing a typedef using non-Latin characters in it's file name, a problem could occur when wiring to the FPGA Read/Write Node where LabVIEW will attempt to find the typedef fail. Any subsequent operation on the Read Write Node attempts to find the typedef again and continues to fail. Workaround: When saving typedefs used on your FPGA VI's front panel, use Latin characters for the filename of the control.
| |||||
| Documentation | ||||||
| 357728 Return | CLIP Signal Names Cannot Start With a Number When generating XML for CLIP, giving a signal a name that starts with a number results in the following error: "An XML name attribute was found with unsupported characters. This name attribute must only contain English letters and numbers, periods, dashes, and underscores." This error does not accurately describe the full limitation of CLIP signal naming conventions. Workaround: Do not use signal names that start with a number.
| |||||
| Example Programs | ||||||
| 356357 Return | Some FPGA Examples utilized deprecated static mode for the Open FPGA VI Reference. Several LabVIEW FPGA examples utilized static mode in the Open FPGA VI Reference. This can lead to the Open FPGA VI Reference to be unable to locate the FPGA VI it is referencing when the example is modified to run on a target different than the example was initially designed. Workaround: Redrop the FPGA VI to the RT Host VI or modify the Open FPGA VI Reference to use dynamic mode.
| |||||
| External 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.
| |||||
| 303501 Return | Xilinx compile errors occur when using the IP Integration Node to integrate VHDL with string constants defined in package files in the generic and/or port declaration. When you use IP Integration Node to wrap your IP and the top-level VHDL has constants or types in the generic and/or port declaration which are defined in your package files, a Xilinx error will be reported saying that the string constants are not declared when you compile. Workaround: Add full namespace to the string constants in the generic and/or port declaration of the top-level VHDL.
| |||||
| 357304 Return | LabVIEW FPGA Derived Clocks Do Not Behave Properly Within FlexRIO Adapter Module CLIP The enable signal to a BUFGCE of a derived clock requires the derived clock to be preset (out of a BUFG from the DCM). This is problematic because the adapter module goes through a power cycle during the download, reset, and close with reset methods. This causes the external clock from CLIP to shut off, and the clock remains turned off until sometime after the adapter module resumes power. In Short: 1. When reset is asserted, the FAM CLIP disables it's clock, and the derived clock's BUFGCE is still enabled even though there is no clock at the input of the DCM. 2. The derived clock valid signal remains high out of reset even though the CLIP has the source clock valid signal low (it's reset state) and has not yet supplied a clock. Workaround: Derive all needed clocks within the CLIP itself and disable support for user derived clocks in LabVIEW FPGA via the CLIP XML.
| |||||
| 367523 Return | EDF Files not supported for Virtex-II Targets Trying to import an EDF file via an IP Integration Node fails when generating support files for Virtex-II targets. Workaround: N/A
| |||||
| 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.
| |||||
| 359537 Return | U8/I8 Look-Up Table Datatypes on Spartan6 Targets Use 36bit Data Width When a Look-Up Table is configured for U8 or I8 datatypes, it will use a 36 bit width instead of 9 as expected. This may cause the Look-Up Table to use more resources than are available, and a Xilinx compile error will be thrown (ERROR:NgdBuild:76). Workaround: Do not use a U8/I8 Look-Up Table with more than 80,000 elements, or use I16/U16 datatypes.
| |||||
| 310755 Return | FIFO Name Discrepancies may Cause Error -61206 If a DMA FIFO has a mismatch in capitalization between its name and what the FPGA interface expects, then error -61206: "The configured item does not exist". Workaround: Use lower case letters for FIFO names
| |||||
| 313940 Return | The Mean,Variance, and Standard Deviation Express VI may Return Invalid Values Due to a roundoff error that may occur with small variance values relative to the mean, the Mean,Variance, and Standard Deviation Express VI may return incorrect results for signals with a substantial DC offset. Workaround: Edit the SubVI to adapt it to a configuration that meets your application's specific needs. For more information, please see the following forum thread: http://forums.ni.com/t5/LabVIEW/labview-2010-FPGA-problem-with-mean-variance-subvi/td-p/1659110
| |||||
| 337185 Return | Using Occurrences in an RT VI Will Fail With Nondescript Error Using a read/write control to pass an occurence reference up from the FPGA to the RT system results in either error -61206 error or copy cvt refnum, csrc=0x7 during RT compilation. Workaround: Occurrences are meant only for FPGA level synchronization. Please use interrupts to synchronize between the host and target.
| |||||
| 357204 Return | Compound Arithmetic Function may Return Different Results Than the Desktop for Single Point Operations The Compound Arithmetic function may execute operations in a different order on the FPGA than on the desktop, producing slightly different results for floating-point operations. The differences include small rounding discrepancies as well as NaN and Inf behavior. Workaround: Decompose the Compound Arithmetic Function into individual arithmetic functions to force the order of operations to conform to what you expect.
| |||||
| 345637 Return | VIs containing Peer To Peer Reader nodes result in compile error when the VI is Saved for Previous If an FPGA VI includes a Peer To Peer Reader node and the VI is saved for previous for 2011, the VI will return a compile error when built in LabVIEW 2011: Compiler Error. Report this problem to National Instruments Tech Support copy cvt, csrc=0x53 Workaround: NA
| |||||
| 380249 Return | Converting the "Look-up Table 1D" Express VI to a sub-VI may cause LabVIEW to hang during compilation Converting the "Look-up Table 1D" Express VI to a sub-VI generates invalid LabVIEW FPGA code, that causes a crash or hang during the generation of intermediate files. Workaround: Use the Express VI without converting it to a sub-VI
| |||||
| 367523 Return | EDF Files not supported for Virtex-II Targets Trying to import an EDF file via an IP Integration Node fails when generating support files for Virtex-II targets. Workaround: N/A
| |||||
| 352262 Return | "In Range and Coerce" behavior mismatch between host and FPGA execution for FXP types The "In Range?" output behavior or the "In Range and Coerce" function doesn't match the desktop for cases where FXP inputs are rounded to the 64-bit word length limit (due to non-aligned or disjoint input types). LabVIEW FPGA rounds the inputs to the output type before doing the comparisons, whereas the desktop does a true numeric comparison before coercing to the output type. Workaround: Use coerce inputs to the same type before passing them to the "In Range and Coerce" function to force the same behavior.
| |||||
| 364995 Return | Accessing FIFOs in non-running clock domains causes a "Hardware Failure" error Accessing the FIFO methods for a FIFO that exists in a clock domain whose clock is not running generates a "Hardware Failure" error message. Workaround: Ensure that clocks are running before accessing FIFOs from the host.
| |||||
| Installation and Activation | ||||||
| 306365 Return | Some Xilinx IP palette functions require separate licensing from Xilinx For some functions on the Xilinx IP palette, when launching Xilinx CoreGenerator, you may see a dialog indicating the core is not licensed. To obtain licenses for these cores, visit http://www.xilinx.com/products/intellectual-property/index.htm. Workaround: NA
| |||||
| 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.
| |||||
| Miscellaneous | ||||||
| 333373 Return | Some versions of glibc cause the Xilinx Compile Worker to fail When using RedHat Enterprise Linux as a compile worker, it is possible to get an error similar to the following: "*** glibc detected *** /usr/local/natinst/NIFPGA/programs/xilinx13_3/ISE/bin/lin/unwrapped/trce: double free or corruption (!prev): 0x09c05b10 ***" For more details see redhat errata: http://rhn.redhat.com/errata/RHBA-2011-1488.html Workaround: Use the command "yum info glibc" and compare your version against the one listed on the errata page, then revert or update the glibc package to one that does not have the issue.
| |||||
| 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.
| |||||
| 353606 Return | Installing LabVIEW 2012 FPGA Compile Tools 13.4 may cause the 12.4 tools to fail if not installed to the default directory If the LabVIEW 2012 FPGA Compile Tools 13.4 are installed on top of an existing 12.4 installation, the default directory registry key for the 12.4 installation is removed. This will cause LabVIEW 2011 compilations to fail to connect if the tools are not installed to the default directory (C:\NIFPGA). Workaround: Add this registry key 'WorkingDirectory' with a value of '[FPGA Compile Tools Location]', under HKLM\SOFTWARE\National Instruments\LabVIEW\11.0\AddOns\FPGA.
| |||||
| 379351 Return | Local variable reads inside FPGA subVIs always return default data
| |||||
| Upgrade - Migration | ||||||
| 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