Print
PDFOverview
This document contains the LabVIEW FPGA IP Builder known issues that were discovered before and since the release of LabVIEW FPGA IP Builder Early Access Program. 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 2011 Platform Known Issues contains a full listing of known issues, including LabVIEW toolkits and modules.
Known Issues by Category
The following items are known issues in sorted by Category.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| LV FPGA IP Builder | ||||||
| 308010 Return |
LabVIEW might crash or return errors if you fully unroll a large loop structure If the algorithm VI contains a loop structure and the number of iterations is greater than 128, fully unrolling this loop might cause LabVIEW to crash or return errors. The following directive settings might fully unroll a loop structure: * You set the "Unroll factor" directive of a loop, whose value equals the number of iterations. * You set the "Initiation interval" directive of a VI whose hierarchy includes the loop structure. * You set the "Initiation interval" directive of a loop that contains a nested loop, and the number of iterations of the nested loop is greater than 128. Workaround: Avoid fully unrolling a large loop structure. For example, use a small value for the "Unroll factor" directive.
|
|||||
| 318687 Return |
Incorrect result is returned when the integer word length of a fixed-point number is out of range If you use a fixed-point number whose integer word length is out of the range [-1024, 1023], you might get an incorrect result when using the generated FPGA IP. Workaround: Ensure the integer word length of fixed-point numbers is within the valid range.
|
|||||
| 326223 Return |
Estimated DSP48s usage might be incorrect if you specify the number of pipeline stages for multipliers If you manually specify a value for the "Number of pipeline stages" directive, you might find that the estimated DSP48s usage is significantly different from the actual compilation result. Workaround: None.
|
|||||
| 326356 Return |
LabVIEW takes a long time to process large-size array constants If the algorithm VI contains an array constant with more than 10,000 elements, LabVIEW might take a long time to generate the estimation reports or the FPGA IP. Workaround: None.
|
|||||
| 328064 Return |
LabVIEW might appear as No Responding when generating FPGA IP If the algorithm VI uses a large-size array control on the interface, and if this array control uses the "All elements" directive option, it might take more than five minutes to generate FPGA IP from this algorithm VI. LabVIEW might freeze or appear as No Responding. In fact, LabVIEW is still working and saving the FPGA IP. Workaround: Avoid using the "All element" directive option, especially for large-size arrays. Wait enough time for LabVIEW to finish saving the FPGA IP.
|
|||||
| 328077 Return |
Compilation errors might occur if different Multiply functions share the same input terminal If the algorithm VI contains several Multiply functions and they share the same input terminal, you might get the following errors when compiling the generated FPGA IP: 1. Error: Place: 673 2. Error: PhyDesignRules:1535 3. Error: Pack: 1654 4. Error: Pack: 1642 5. Error: Route: 471 Workaround: Apply the "Number of pipeline stages" directive to the Multiply functions, or apply the "Initiation interval" directive to the VI that contains these functions. If the compilation errors persist, contact National Instruments.
|
|||||
| 330260 Return |
Feedback signals might be incorrect if the interface is a combination of element-by-element, unbuffered inputs and element-by-element, buffered inputs Public Details: If the inputs of your algorithm VI are all arrays and if you use all the following directive settings in one FPGA IP design: * Element-by-element, buffered inputs * Element-by-element, unbuffered inputs * Initiation interval of the top-level VI The feedback signals of the generated FPGA IP might behave incorrectly. For example, assume that you have two input arrays: array A with a size of Na and array B with a size of Nb; array A is using the "Element-by-element, buffered" option, and array B is using the "Element-by-element, unbuffered" option. If you have fed Na elements to array A but only n (Nb) elements to array B, the "ready for A" feedback signal becomes TRUE, while it should be FALSE. Workaround: Do not use the three directive settings mentioned in the details section in one FPGA IP design. If you want to use the "Initiation interval" directive, you then must ensure the interface directives use the same option. If you want to use different interface directive options, do not use the "Initiation interval" directive of the top-level VI.
|
|||||
| 336983 Return |
LabVIEW does not return estimation errors despite conflicts between directive settings LabVIEW might 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.
|
|||||
Known Issues by Date
The following items are known issues in sorted by Date.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 308010 Return |
LabVIEW might crash or return errors if you fully unroll a large loop structure If the algorithm VI contains a loop structure and the number of iterations is greater than 128, fully unrolling this loop might cause LabVIEW to crash or return errors. The following directive settings might fully unroll a loop structure: * You set the "Unroll factor" directive of a loop, whose value equals the number of iterations. * You set the "Initiation interval" directive of a VI whose hierarchy includes the loop structure. * You set the "Initiation interval" directive of a loop that contains a nested loop, and the number of iterations of the nested loop is greater than 128. Workaround: Avoid fully unrolling a large loop structure. For example, use a small value for the "Unroll factor" directive.
|
|||||
| 318687 Return |
Incorrect result is returned when the integer word length of a fixed-point number is out of range If you use a fixed-point number whose integer word length is out of the range [-1024, 1023], you might get an incorrect result when using the generated FPGA IP. Workaround: Ensure the integer word length of fixed-point numbers is within the valid range.
|
|||||
| 326223 Return |
Estimated DSP48s usage might be incorrect if you specify the number of pipeline stages for multipliers If you manually specify a value for the "Number of pipeline stages" directive, you might find that the estimated DSP48s usage is significantly different from the actual compilation result. Workaround: None.
|
|||||
| 326356 Return |
LabVIEW takes a long time to process large-size array constants If the algorithm VI contains an array constant with more than 10,000 elements, LabVIEW might take a long time to generate the estimation reports or the FPGA IP. Workaround: None.
|
|||||
| 328064 Return |
LabVIEW might appear as No Responding when generating FPGA IP If the algorithm VI uses a large-size array control on the interface, and if this array control uses the "All elements" directive option, it might take more than five minutes to generate FPGA IP from this algorithm VI. LabVIEW might freeze or appear as No Responding. In fact, LabVIEW is still working and saving the FPGA IP. Workaround: Avoid using the "All element" directive option, especially for large-size arrays. Wait enough time for LabVIEW to finish saving the FPGA IP.
|
|||||
| 328077 Return |
Compilation errors might occur if different Multiply functions share the same input terminal If the algorithm VI contains several Multiply functions and they share the same input terminal, you might get the following errors when compiling the generated FPGA IP: 1. Error: Place: 673 2. Error: PhyDesignRules:1535 3. Error: Pack: 1654 4. Error: Pack: 1642 5. Error: Route: 471 Workaround: Apply the "Number of pipeline stages" directive to the Multiply functions, or apply the "Initiation interval" directive to the VI that contains these functions. If the compilation errors persist, contact National Instruments.
|
|||||
| 330260 Return |
Feedback signals might be incorrect if the interface is a combination of element-by-element, unbuffered inputs and element-by-element, buffered inputs Public Details: If the inputs of your algorithm VI are all arrays and if you use all the following directive settings in one FPGA IP design: * Element-by-element, buffered inputs * Element-by-element, unbuffered inputs * Initiation interval of the top-level VI The feedback signals of the generated FPGA IP might behave incorrectly. For example, assume that you have two input arrays: array A with a size of Na and array B with a size of Nb; array A is using the "Element-by-element, buffered" option, and array B is using the "Element-by-element, unbuffered" option. If you have fed Na elements to array A but only n (Nb) elements to array B, the "ready for A" feedback signal becomes TRUE, while it should be FALSE. Workaround: Do not use the three directive settings mentioned in the details section in one FPGA IP design. If you want to use the "Initiation interval" directive, you then must ensure the interface directives use the same option. If you want to use different interface directive options, do not use the "Initiation interval" directive of the top-level VI.
|
|||||
| 336983 Return |
LabVIEW does not return estimation errors despite conflicts between directive settings LabVIEW might 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.
|
Document last updated on 2/22/2012
Reader Comments | Submit a comment »
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).