This document contains the LabVIEW 2014 FPGA Module known issues that were discovered before and since the release of LabVIEW 2014 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 2014 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
The following items are known issues in LabVIEW 2014 FPGA Module sorted by Category.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| Building and Distributing LabVIEW Applications | ||||||
| 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
| |||||
| Compatibility | ||||||
| 401659 Return | Having mismatched versions of the LabVIEW FPGA Compile Server and Client produces a confusing error message If the 2012 version of the Compile Server is installed, and attempts to compile to a 2013 Client, the user will receive the following error: An error occurred attempting to connect to this compile server. Details: NI-Farm: Cannot communicate with the NI-Farm server using the specified communication protocol. Workaround: Install the 2013 version of the NI Compile Server.
| |||||
| External Code | ||||||
| 472896 Return | VHDL with syntax error using 3rd party simulation on Vivado target throws error: No Error or xsim.dir Not Found If CLIP has a syntax error, 3rd party simulation on a Vivado target will not tell the user about the syntax error. Instead the simulation will fail and either throw no error or tell the user that xsim.dir was not found. Workaround: Run syntax check outside of LabVIEW.
| |||||
| 481551 Return | VHDL with syntax error using 3rd party simulation on Vivado target throws error: No Error or xsim.dir Not Found If CLIP has a syntax error, 3rd party simulation on a Vivado target will not tell the user about the syntax error. Instead the simulation will fail and either throw no error or tell the user that xsim.dir was not found. Workaround: Run syntax check outside of LabVIEW.
| |||||
| 482044 Return | The terminal names for the Xilinx Color Filter Array are different than what is documented in the datasheet When configuring the Xilinx Color Filter Array after launching it in LabVIEW, the IP terminals are named a, b, c, and p. It is not known which terminal maps to which as they do not correspond to the datasheet. Workaround: You can use IPIN instead by generating the same IP on the target in ISE. Then use the corresponding .ngc file under the folder /ipcore_dir as the synthesis file of the IPIN node and use the .vhd file in the same folder as the user-defined simulation file. On IPIN's second configuration page, select the correct simulation entity, and go through the other configuration page to use the IPIN node.
| |||||
| Functions, VIs, and Express VIs | ||||||
| 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
| |||||
| 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.
| |||||
| 413443 Return | The IP Integration Node configuration window may hang If the IP Integration node references a file whose path on disk is longer than 140 characters will hang an underlying dependency of the IP Integration Node. Workaround: Restrict the file path length of any files referenced by the IP Integration node to 140 characters
| |||||
| 401546 Return | Memory Item Simulation may not match in hardware behavior It is possible to successfully simulate a memory item set to "Never Arbitrate" and then accessed simultaneously by two different Read Methods. This will not work in hardware, and may cause compilation failures Workaround: N/A
| |||||
| 404665 Return | The FIFO.configure method only clears the FIFO contents if a new Actual Depth is set According to the LabVIEW FPGA help documentation, the FIFO.configure method will clear the contents of the host-side FIFO buffer. This is not true if the FIFO.configure method does not change the "Actual Depth" of the host-side FIFO. Workaround: Use FIFO.Stop and FIFO.Start to clear the host-side FIFO buffer.
| |||||
| 434094 Return | Using a homogenous cluster as the x input to an "In Range and Coerce" primitive may cause compilation errors. When a homogeneous cluster is used as the x input to an "In Range and Coerce" primitive and the "Coerced(x)" output is not wired to anything, HDL errors may occur during compilation. Workaround: Wire an indicator to the "Coerced(x)" output of the primitive.
| |||||
| 356730 Return | Open an VI contains IP Integration Node in previous version of LabVIEW may return a unexpected error. Open an VI contains IP Integration Node in previous version of LabVIEW will break the VI, but it may return a unexpected error. It happens when all the below conditions are met: 1) the IPIN is configured well, which means it has an simulation dll on the disk. 2) user saves that VI/project into same folder. 3) user opens the saved project using previous LabVIEW, and the original simulation dll still exist on the disk and IPIN can find that dll based on a relative path. Cause: it's because LabVIEW creates a link between an IP Integration Node and its simulation dll by the dll path. After we saved this IPIN for previous, it's still linked to that dll, but this dll should be obsoleted for the old version IPIN. When opening the saved VI in previous LabVIEW, if IPIN still can find that simulation dll on disk by relative path, it will produce an unexpected error. Workaround: 1)Before opening the saved project on the same machine, move the saved folder to another place first, or delete the original *.dll. 2)Before opening the saved project on another machine, only copy the saved folder, do not copy the *.dll along with it.
| |||||
| 442745 Return | RF-RIO Instr Default Personality 5646R.lvproj's FPGA VI will hang on save. Instrument driver\RFSA\5645R\Public\Apply Digital Correction.vi located in RF-RIO Instr Default Personality 5646R.lvproj will hang on save. This happens when removing the diagram disable structure. In addition, the VI cannot compile. Workaround: Currently, using the structure wrap included in the example code is recommended. If you only use one instance of the polymorphic VI, re-arrange the instances such that the instance you wish to use appears first in the list.
| |||||
| 465035 Return | Enum increment saturates on FPGA, but wraps on host and emulation If you increment the highest valid value of an enum, the value stays the same when executing on the FPGA, but LabVIEW Host code (and FPGA emulation on host) wraps around to the lowest valid enum value. Workaround: Implement bound checking in code.
| |||||
| 474728 Return | Wiring an empty class to a left shift register causes a Xilinx compilation failure An empty private LabVIEW class wired as a constant to the left shift register on a while loop will cause a Xilinx compilation failure when attempting to compile. You will receive the error: ERROR: [Synth 8-2029] formal shift_in has no actual or default value Workaround: Place a value in the private class to prevent the class from being empty.
| |||||
| 481717 Return | Inconsistent enum type behavior in simulation versus in hardware In simulation, when an enum type is incremented, it wraps as expected at the highest item. In hardware, when an enum type is incremented, the wrap happens at the data type boundary (i.e. U18, U16, etc) and the enum saturates at its highest item. Workaround: Do not increment the value past the defined limits of the enum or avoid using enums.
| |||||
| IP Builder | ||||||
| 336983 Return | LabVIEW does not return estimation errors despite conflicts between directive settings LabVIEW may not return estimation errors, but may return build errors when you configure directive settings that conflict with each other. For example, if the top-level VI of the algorithm contains an array control and you wire this array directly into a subVI. In the subVI, you access the array elements sequentially. LabVIEW does not return estimation errors if you apply the following directive settings that conflict with each other: * Use the "Element-by-element, unbuffered" option for the array control on the top-level VI interface; * Use the "Complete" partition type for the same array in the subVI. Workaround: Do not specify conflicting directives. To resolve the build error in this specific example, either change "Element-by-element, unbuffered" to "All elements" or disable partitioning for this array.
| |||||
| 315926 Return | FPGA IP Builder does not support Boolean controls with latch mechanical actions FPGA IP Builder does not implement the latch mechanical actions on Boolean controls. All Boolean controls in the FPGA IP Builder context are treated as controls with switching mechanical actions. Workaround: Modify the Boolean controls to use the switching mechanical action.
| |||||
| 356405 Return | Unexpected error might occur if the algorithm VI contains FPGA Module Express VIs If the algorithm VI contains any of the following FPGA Module Express VIs, you still can create a directives item for this VI. You also can create build specifications for this directives item. However, an unexpected error might occur when you double-click this directives item or generate FPGA IP from the build specifications: * Sine Wave Generator * Square Wave Generator * White Noise Generator * Quantizer * Basic Discrete Delay * Look-Up Table 1D Workaround: When you create algorithm VIs, avoid using the FPGA Module Express VIs listed above.
| |||||
| 395702 Return | FPGA IP Builder-generated VIs do not strictly distinguish between SGL positive zero and SGL negative zero FPGA IP Builder does not guarantee the sign bit accuracy for SGL positive zero values and SGL negative zero values of FPGA IP Builder-generated VIs. You may get an SGL negative zero value result in FPGA IP Builder-generated VIs, even though you get an SGL positive zero value result in LabVIEW. Workaround: N/A
| |||||
| 411104 Return | FPGA IP Builder-generated VIs do not produce full-precision results for SGL reciprocal operations on Spartan-6, Virtex-6, Kintex-7, and Zynq targets FPGA IP Builder does not guarantee the least-significant bit accuracy for SGL reciprocal operation results of FPGA IP Builder-generated VIs on Spartan-6, Virtex-6, Kintex-7, or Zynq targets. Although FPGA IP Builder does not support SGL functionality for the Reciprocal function directly, you may use the Divide function or the Compound Arithmetic function to perform SGL reciprocal operations. However, SGL reciprocal operations may produce different results in FPGA IP Builder-generated VIs than in LabVIEW. Workaround: If you want to calculate full-precision reciprocal results of SGL data y on Spartan-6, Virtex-6, Kintex-7, or Zynq targets, follow these steps: first, create an SGL control x in the top-level algorithm VI; second, connect the control x to the connector pane of the top-level algorithm VI; third, connect the control x to the x input of the Divide function and data y to the y input of the Divide function; next, compile the algorithm VI; finally, set x to 1.0 in the top-level VI when you invoke the generated VI.
| |||||
| 454094 Return | Algorithm VIs having internal word lengths longer than 1024-bit can fail estimation or build of FPGA IPs If your algorithm VIs include functions that requires bit-width longer than 1024 bit in intermediate results, LabVIEW can fail estimation or build of FPGA IPs. Workaround: Change datatype of input or output of the functions, to shorten internal word lengths required to calculate output values.
| |||||
| 472275 Return | You may lose the directive settings for a SubVI when changing the data type of one of the SubVI's integer controls If a SubVI has an integer-type control that determines the size of an array within the SubVI and you change the control's data type to a different integer type, you will lose any directive settings that were previously set for the SubVI. If the old type and new type are both in the set of U8/I8/U16/I16, your design is not affected by changing the data type. Workaround: N/A
| |||||
| 474620 Return | FPGA Memory implemented by Block RAM may fail compilation on ISE targets If you compile an FPGA VI that includes any FPGA memory that are configured to have width equals 162 bit and depth equals 6830, you may run into failure in compiling the VI for an ISE target. In such case, you can find the following error message in the Xilinx log file: _ipguilauncher.exe has stopped working. This is a known issue to ISE 14.7 that Block RAM Generator v7.3 can fail generation in some configurations of the core. Workaround: Configure the width of memory to have 1+ bits.
| |||||
| 474709 Return | Large size constant array of fixed-point type or integer type may lead to very long estimation/build time If there is a large size constant array of fixed-point type or integer type on the block diagram, it may take long time for estimating the design or build the IP Builder generated VI. When the size reaches 50000, it could take 30 minutes for IP Builder to analyze the values of the constant array. If the size reaches 200000 or more, it could take hours for IP Builder to analyze the values of the constant array. Usually, it takes more time for IP Builder to analyze the values of a constant array of fixed-point type, compared with analyzing the values of a constant array of integer type. On a Win-32 OS, sometimes, the esitmation or build could lead to crash of Vivado_HLS tool chain. Workaround: If it's a very large size fixed-point constant array, considering making it an integer constant array and use Integer To Fixed-Point Cast node to cast the integer value to fixed-point after indexing the element from the array. If running into Vivado_HLS crash on a Win-32 OS, considering doing the design on a Win-64 OS.
| |||||
| 476780 Return | Using a partitioned array to buffer an Element-by-element, unbuffered input array directly may work incorrectly for non-continuous valid inputs In FPGA IP Builder, if you wire the control terminal of an array control input of a top-level VI to an auto-indexed tunnel input of a For loop structure, and directly connect the auto-indexed tunnel input to an auto-indexed output tunnel of the For loop, you can configure directives for an array buffer corresponding to the auto-indexed output tunnel of the For loop. If you specify the interface for the array control as Element-by-element, unbuffered and specify the Partition type directive on the array buffer, you can achieve a design which increases the number of elements to access in parallel of the input array control. However, when you use the generated IP, if you cannot always provide a valid data whenever the IP asks for the corresponding array input, the IP may act incorrectly. Workaround: When using the generated IP, add a FIFO between the upstream data source and the generated IP to buffer the data. Only start to read the FIFO after the FIFO collects a number of inputs which is larger than the array size.
| |||||
| 479072 Return | Estimation fails when I specify an array control, which is auto-indexed into a for loop on the top-level diagram, as Element-by-element, unbuffered interface If a top-level array control is auto-indexed into a for loop on the top-level diagram and is configured as Element-by-element, unbuffered interface, you might get an error as "Some arrays of the top-level VI cannot be "Element-by-element, unbuffered" interfaces. Use "Element-by-element, buffered" instead. Refer to the Design Feedback report for more information." when you request for an estimate of the design.". The Design Feedback lists out which control is affected and what are the possible reasons. If you think your algorithm VI does not violate any of the rule, you may want to check whether any variable-sized array is participating in deciding the for loop iteration. For example, a constant array, which is not specified as fixed-size array, or an array originated from a feedback node which is initialized by a non fixed-size constant array, is auto-indexed in to a for loop structure. Moving the mouse over the wire and checking the context help for the wire data type to decide whether an array is regarded as fixed-size array by LabVIEW. Workaround: Identify the constant array and specify it as a fixed-size array by right-clicking the array constant and selecting Set Size... menu item for configuration.
| |||||
| Miscellaneous | ||||||
| 403070 Return | The LabVIEW FPGA Compile Worker may fail to shutdown properly If a Xilinx process hangs during compilation, then the FPGA Compile worker may fail to shutdown properly. Workaround: Manually kill the hung Xilinx process
| |||||
| 410377 Return | Simulating a FPGA VI that contains IP Integration Nodes may lock up LabVIEW Simulating a FPGA VI (in both My Computer and FPGA Contexts) that contains IP Integration Nodes may cause a dialog that states that Xilinx is out of memory or LabVIEW may lock up. This only occurs if users start and stop the VI multiple times or has a Host VI that opens, runs, and closes the VI multiple times. Cause: Memory leaks in third-party tools cause the IP Integration Node to leak memory during its initialization routines. Running this initialization routine multiple times can cause the system to run out of memory causing the third party tools to error out or crash, resulting in LabVIEW becoming unresponsive. Workaround: Avoid simulating multiple IP Integration Nodes and/or avoid simulating your FPGA VI multiple times in the same instance of LabVIEW. Shutdown LabVIEW to allow the third party tools to release the leaked memory.
| |||||
| 451587 Return | Warning 1 (code: 1, status: false) error thrown with incorrect data read and written in FPGA simulation When registers are being read or written with the same name, LabVIEW FPGA Interface will throw a warning and read and write incorrect data from an FPGA VI running in simulation mode. Workaround: Change register names to be different
| |||||
The following items are known issues in LabVIEW 2014 FPGA Module sorted by Date.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 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.
| |||||
| 336983 Return | LabVIEW does not return estimation errors despite conflicts between directive settings LabVIEW may not return estimation errors, but may return build errors when you configure directive settings that conflict with each other. For example, if the top-level VI of the algorithm contains an array control and you wire this array directly into a subVI. In the subVI, you access the array elements sequentially. LabVIEW does not return estimation errors if you apply the following directive settings that conflict with each other: * Use the "Element-by-element, unbuffered" option for the array control on the top-level VI interface; * Use the "Complete" partition type for the same array in the subVI. Workaround: Do not specify conflicting directives. To resolve the build error in this specific example, either change "Element-by-element, unbuffered" to "All elements" or disable partitioning for this array.
| |||||
| 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
| |||||
| 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.
| |||||
| 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
| |||||
| 315926 Return | FPGA IP Builder does not support Boolean controls with latch mechanical actions FPGA IP Builder does not implement the latch mechanical actions on Boolean controls. All Boolean controls in the FPGA IP Builder context are treated as controls with switching mechanical actions. Workaround: Modify the Boolean controls to use the switching mechanical action.
| |||||
| 356405 Return | Unexpected error might occur if the algorithm VI contains FPGA Module Express VIs If the algorithm VI contains any of the following FPGA Module Express VIs, you still can create a directives item for this VI. You also can create build specifications for this directives item. However, an unexpected error might occur when you double-click this directives item or generate FPGA IP from the build specifications: * Sine Wave Generator * Square Wave Generator * White Noise Generator * Quantizer * Basic Discrete Delay * Look-Up Table 1D Workaround: When you create algorithm VIs, avoid using the FPGA Module Express VIs listed above.
| |||||
| 413443 Return | The IP Integration Node configuration window may hang If the IP Integration node references a file whose path on disk is longer than 140 characters will hang an underlying dependency of the IP Integration Node. Workaround: Restrict the file path length of any files referenced by the IP Integration node to 140 characters
| |||||
| 395702 Return | FPGA IP Builder-generated VIs do not strictly distinguish between SGL positive zero and SGL negative zero FPGA IP Builder does not guarantee the sign bit accuracy for SGL positive zero values and SGL negative zero values of FPGA IP Builder-generated VIs. You may get an SGL negative zero value result in FPGA IP Builder-generated VIs, even though you get an SGL positive zero value result in LabVIEW. Workaround: N/A
| |||||
| 411104 Return | FPGA IP Builder-generated VIs do not produce full-precision results for SGL reciprocal operations on Spartan-6, Virtex-6, Kintex-7, and Zynq targets FPGA IP Builder does not guarantee the least-significant bit accuracy for SGL reciprocal operation results of FPGA IP Builder-generated VIs on Spartan-6, Virtex-6, Kintex-7, or Zynq targets. Although FPGA IP Builder does not support SGL functionality for the Reciprocal function directly, you may use the Divide function or the Compound Arithmetic function to perform SGL reciprocal operations. However, SGL reciprocal operations may produce different results in FPGA IP Builder-generated VIs than in LabVIEW. Workaround: If you want to calculate full-precision reciprocal results of SGL data y on Spartan-6, Virtex-6, Kintex-7, or Zynq targets, follow these steps: first, create an SGL control x in the top-level algorithm VI; second, connect the control x to the connector pane of the top-level algorithm VI; third, connect the control x to the x input of the Divide function and data y to the y input of the Divide function; next, compile the algorithm VI; finally, set x to 1.0 in the top-level VI when you invoke the generated VI.
| |||||
| 401546 Return | Memory Item Simulation may not match in hardware behavior It is possible to successfully simulate a memory item set to "Never Arbitrate" and then accessed simultaneously by two different Read Methods. This will not work in hardware, and may cause compilation failures Workaround: N/A
| |||||
| 401659 Return | Having mismatched versions of the LabVIEW FPGA Compile Server and Client produces a confusing error message If the 2012 version of the Compile Server is installed, and attempts to compile to a 2013 Client, the user will receive the following error: An error occurred attempting to connect to this compile server. Details: NI-Farm: Cannot communicate with the NI-Farm server using the specified communication protocol. Workaround: Install the 2013 version of the NI Compile Server.
| |||||
| 403070 Return | The LabVIEW FPGA Compile Worker may fail to shutdown properly If a Xilinx process hangs during compilation, then the FPGA Compile worker may fail to shutdown properly. Workaround: Manually kill the hung Xilinx process
| |||||
| 404665 Return | The FIFO.configure method only clears the FIFO contents if a new Actual Depth is set According to the LabVIEW FPGA help documentation, the FIFO.configure method will clear the contents of the host-side FIFO buffer. This is not true if the FIFO.configure method does not change the "Actual Depth" of the host-side FIFO. Workaround: Use FIFO.Stop and FIFO.Start to clear the host-side FIFO buffer.
| |||||
| 410377 Return | Simulating a FPGA VI that contains IP Integration Nodes may lock up LabVIEW Simulating a FPGA VI (in both My Computer and FPGA Contexts) that contains IP Integration Nodes may cause a dialog that states that Xilinx is out of memory or LabVIEW may lock up. This only occurs if users start and stop the VI multiple times or has a Host VI that opens, runs, and closes the VI multiple times. Cause: Memory leaks in third-party tools cause the IP Integration Node to leak memory during its initialization routines. Running this initialization routine multiple times can cause the system to run out of memory causing the third party tools to error out or crash, resulting in LabVIEW becoming unresponsive. Workaround: Avoid simulating multiple IP Integration Nodes and/or avoid simulating your FPGA VI multiple times in the same instance of LabVIEW. Shutdown LabVIEW to allow the third party tools to release the leaked memory.
| |||||
| 434094 Return | Using a homogenous cluster as the x input to an "In Range and Coerce" primitive may cause compilation errors. When a homogeneous cluster is used as the x input to an "In Range and Coerce" primitive and the "Coerced(x)" output is not wired to anything, HDL errors may occur during compilation. Workaround: Wire an indicator to the "Coerced(x)" output of the primitive.
| |||||
| 356730 Return | Open an VI contains IP Integration Node in previous version of LabVIEW may return a unexpected error. Open an VI contains IP Integration Node in previous version of LabVIEW will break the VI, but it may return a unexpected error. It happens when all the below conditions are met: 1) the IPIN is configured well, which means it has an simulation dll on the disk. 2) user saves that VI/project into same folder. 3) user opens the saved project using previous LabVIEW, and the original simulation dll still exist on the disk and IPIN can find that dll based on a relative path. Cause: it's because LabVIEW creates a link between an IP Integration Node and its simulation dll by the dll path. After we saved this IPIN for previous, it's still linked to that dll, but this dll should be obsoleted for the old version IPIN. When opening the saved VI in previous LabVIEW, if IPIN still can find that simulation dll on disk by relative path, it will produce an unexpected error. Workaround: 1)Before opening the saved project on the same machine, move the saved folder to another place first, or delete the original *.dll. 2)Before opening the saved project on another machine, only copy the saved folder, do not copy the *.dll along with it.
| |||||
| 442745 Return | RF-RIO Instr Default Personality 5646R.lvproj's FPGA VI will hang on save. Instrument driver\RFSA\5645R\Public\Apply Digital Correction.vi located in RF-RIO Instr Default Personality 5646R.lvproj will hang on save. This happens when removing the diagram disable structure. In addition, the VI cannot compile. Workaround: Currently, using the structure wrap included in the example code is recommended. If you only use one instance of the polymorphic VI, re-arrange the instances such that the instance you wish to use appears first in the list.
| |||||
| 451587 Return | Warning 1 (code: 1, status: false) error thrown with incorrect data read and written in FPGA simulation When registers are being read or written with the same name, LabVIEW FPGA Interface will throw a warning and read and write incorrect data from an FPGA VI running in simulation mode. Workaround: Change register names to be different
| |||||
| 454094 Return | Algorithm VIs having internal word lengths longer than 1024-bit can fail estimation or build of FPGA IPs If your algorithm VIs include functions that requires bit-width longer than 1024 bit in intermediate results, LabVIEW can fail estimation or build of FPGA IPs. Workaround: Change datatype of input or output of the functions, to shorten internal word lengths required to calculate output values.
| |||||
| 465035 Return | Enum increment saturates on FPGA, but wraps on host and emulation If you increment the highest valid value of an enum, the value stays the same when executing on the FPGA, but LabVIEW Host code (and FPGA emulation on host) wraps around to the lowest valid enum value. Workaround: Implement bound checking in code.
| |||||
| 472275 Return | You may lose the directive settings for a SubVI when changing the data type of one of the SubVI's integer controls If a SubVI has an integer-type control that determines the size of an array within the SubVI and you change the control's data type to a different integer type, you will lose any directive settings that were previously set for the SubVI. If the old type and new type are both in the set of U8/I8/U16/I16, your design is not affected by changing the data type. Workaround: N/A
| |||||
| 472896 Return | VHDL with syntax error using 3rd party simulation on Vivado target throws error: No Error or xsim.dir Not Found If CLIP has a syntax error, 3rd party simulation on a Vivado target will not tell the user about the syntax error. Instead the simulation will fail and either throw no error or tell the user that xsim.dir was not found. Workaround: Run syntax check outside of LabVIEW.
| |||||
| 474620 Return | FPGA Memory implemented by Block RAM may fail compilation on ISE targets If you compile an FPGA VI that includes any FPGA memory that are configured to have width equals 162 bit and depth equals 6830, you may run into failure in compiling the VI for an ISE target. In such case, you can find the following error message in the Xilinx log file: _ipguilauncher.exe has stopped working. This is a known issue to ISE 14.7 that Block RAM Generator v7.3 can fail generation in some configurations of the core. Workaround: Configure the width of memory to have 1+ bits.
| |||||
| 474709 Return | Large size constant array of fixed-point type or integer type may lead to very long estimation/build time If there is a large size constant array of fixed-point type or integer type on the block diagram, it may take long time for estimating the design or build the IP Builder generated VI. When the size reaches 50000, it could take 30 minutes for IP Builder to analyze the values of the constant array. If the size reaches 200000 or more, it could take hours for IP Builder to analyze the values of the constant array. Usually, it takes more time for IP Builder to analyze the values of a constant array of fixed-point type, compared with analyzing the values of a constant array of integer type. On a Win-32 OS, sometimes, the esitmation or build could lead to crash of Vivado_HLS tool chain. Workaround: If it's a very large size fixed-point constant array, considering making it an integer constant array and use Integer To Fixed-Point Cast node to cast the integer value to fixed-point after indexing the element from the array. If running into Vivado_HLS crash on a Win-32 OS, considering doing the design on a Win-64 OS.
| |||||
| 474728 Return | Wiring an empty class to a left shift register causes a Xilinx compilation failure An empty private LabVIEW class wired as a constant to the left shift register on a while loop will cause a Xilinx compilation failure when attempting to compile. You will receive the error: ERROR: [Synth 8-2029] formal shift_in has no actual or default value Workaround: Place a value in the private class to prevent the class from being empty.
| |||||
| 476780 Return | Using a partitioned array to buffer an Element-by-element, unbuffered input array directly may work incorrectly for non-continuous valid inputs In FPGA IP Builder, if you wire the control terminal of an array control input of a top-level VI to an auto-indexed tunnel input of a For loop structure, and directly connect the auto-indexed tunnel input to an auto-indexed output tunnel of the For loop, you can configure directives for an array buffer corresponding to the auto-indexed output tunnel of the For loop. If you specify the interface for the array control as Element-by-element, unbuffered and specify the Partition type directive on the array buffer, you can achieve a design which increases the number of elements to access in parallel of the input array control. However, when you use the generated IP, if you cannot always provide a valid data whenever the IP asks for the corresponding array input, the IP may act incorrectly. Workaround: When using the generated IP, add a FIFO between the upstream data source and the generated IP to buffer the data. Only start to read the FIFO after the FIFO collects a number of inputs which is larger than the array size.
| |||||
| 479072 Return | Estimation fails when I specify an array control, which is auto-indexed into a for loop on the top-level diagram, as Element-by-element, unbuffered interface If a top-level array control is auto-indexed into a for loop on the top-level diagram and is configured as Element-by-element, unbuffered interface, you might get an error as "Some arrays of the top-level VI cannot be "Element-by-element, unbuffered" interfaces. Use "Element-by-element, buffered" instead. Refer to the Design Feedback report for more information." when you request for an estimate of the design.". The Design Feedback lists out which control is affected and what are the possible reasons. If you think your algorithm VI does not violate any of the rule, you may want to check whether any variable-sized array is participating in deciding the for loop iteration. For example, a constant array, which is not specified as fixed-size array, or an array originated from a feedback node which is initialized by a non fixed-size constant array, is auto-indexed in to a for loop structure. Moving the mouse over the wire and checking the context help for the wire data type to decide whether an array is regarded as fixed-size array by LabVIEW. Workaround: Identify the constant array and specify it as a fixed-size array by right-clicking the array constant and selecting Set Size... menu item for configuration.
| |||||
| 481551 Return | VHDL with syntax error using 3rd party simulation on Vivado target throws error: No Error or xsim.dir Not Found If CLIP has a syntax error, 3rd party simulation on a Vivado target will not tell the user about the syntax error. Instead the simulation will fail and either throw no error or tell the user that xsim.dir was not found. Workaround: Run syntax check outside of LabVIEW.
| |||||
| 481717 Return | Inconsistent enum type behavior in simulation versus in hardware In simulation, when an enum type is incremented, it wraps as expected at the highest item. In hardware, when an enum type is incremented, the wrap happens at the data type boundary (i.e. U18, U16, etc) and the enum saturates at its highest item. Workaround: Do not increment the value past the defined limits of the enum or avoid using enums.
| |||||
| 482044 Return | The terminal names for the Xilinx Color Filter Array are different than what is documented in the datasheet When configuring the Xilinx Color Filter Array after launching it in LabVIEW, the IP terminals are named a, b, c, and p. It is not known which terminal maps to which as they do not correspond to the datasheet. Workaround: You can use IPIN instead by generating the same IP on the target in ISE. Then use the corresponding .ngc file under the folder /ipcore_dir as the synthesis file of the IPIN node and use the .vhd file in the same folder as the user-defined simulation file. On IPIN's second configuration page, select the correct simulation entity, and go through the other configuration page to use the IPIN node.
|
Document last updated on 7/17/2014