Known Issues VisualApplets Release 3.3.0
Windows 10 Fall Creators Update (Version 1709) On a PC with a Vivado 2017.2 or Vivado 2017.3 Installation
If you install the Windows 10 Fall Creators update (version 1709) on a PC that has Xilinx Vivado version 2017.2 or 2017.3 installed, Xilinx Vivado may not properly work afterwards. Thus, you may not be able to build the designs you created with VisualApplets.
Follow the workaround provided by Xilinx Support to make your Xilinx Vivado 2017.2 or 2017.3 installation work again. (See https://www.xilinx.com/support/answers/69908.html).
Windows 10 x64 (Version 1803) Cumulative Update from 2017-07-10 (KB4338819) On a PC with an ISE 14.7 or Vivado installation Older Than 2017.4
If you install the above Windows 10 update the build flow may not work properly afterwards using Xilinx tools older than Vivado 2017.4. Thus, you may not be able to build the designs you created with VisualApplets.
For Vivado versions older than Vivado 2017.4 error messages may show up in the log output of the Xilinx tool chain telling that some black box instances have undefined content. For ISE even no Xilinx tool version can be determined and the FPGA Type Check fails.
Follow the workaround provided by Xilinx Support to make the ISE installation work again (See https://www.xilinx.com/support/answers/62380.html, section ISE 14.7 64bit - Turning off SmartHeap). The same workaround can be used for Vivado where you need to perform the file substitution actions in the folder \<VivadoInstallDir>/ids_lite/ISE/lib/nt64.
General
| Summary: | Build Error When Building a Design with Embedded VisualApplets (eVA) |
| Description: | When building a design with embedded VisualApplets, a build error might occur. This affects only VisualApplets version 3.3.0. |
| Affected OS: | Windows 8 |
| Workaround: | Use VisualApplets 3.2.1. |
| Ticket ID: | 233158 |
| Summary: | Applets for mE5 Platforms Can't Be Built with Xilinx Vivado 2020.2 or Higher |
| Description: | Applets for all mE5 platforms can't be built with Vivado 2020.2 or higher. The latest supported Vivado version for these platforms is Vivado 2020.1. |
| Affected OS: | Windows 8 |
| Workaround: | Use Xilinx Vivado 2020.1 or lower to build applets for mE5 platforms. |
| Ticket ID: | 9848 |
| Summary: | On a Windows PC, You Must Define the User Folder as Destination Folder |
| Description: | Important note concerning operating systems Microsoft Windows 8: It is necessary and recommended to define the user folder as destination folder. Alternatively any other folder with full access rights can be used. |
| Affected OS: | Windows 8 |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
| Summary: | When Converting a Design to a Different Hardware Platform, the Hardware-Dependent Operator Library Might Not Be Available |
| Description: | When converting a VisualApplets design to a different hardware platform, then under certain circumstances the hardware-dependent operator library for the target platform might not be available. |
| Workaround: | To resolve this restart VisualApplets. |
| Ticket ID: | – |
| Summary: | The Dialog Build Hardware Platforms Stays Blank During Build |
| Description: | Sometimes the dialog Build Hardware Platforms stays blank during build while the dock window Build Log shows the output. This has no impact on the build flow. |
| Workaround: | To resolve this, cancel and restart the build. |
| Ticket ID: | – |
| Summary: | You Need to Reset Simulation Conditions After a Simulation Error |
| Description: | After a simulation error has occurred, the simulation conditions need to be reset |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
| Summary: | Xilinx Vivado Warning When Building an Applet |
| Description: | When you build an applet using the Xilinx Vivado Tools, you may get critical warnings (in build step LinkDesign). The warnings are due to an issue within the Xilinx tool chain. The issue is known to Xilinx and fixing is in progress. Example:
CRITICAL WARNING: [Shape Builder 18-137] Cannot obey LUTNM/HLUTNM constraint for instances …/PART1174 and …/PART1175. Illegal to place instance …/PART1174 on site SLICE_X2Y0. The location site type does not match the instance type. Instance …/PART1174 belongs to a shape with reference instance …/PART1175. Shape elements have relative placement respect to each other. The invalid location might results from a constraint on any of the instance in the shape..
|
| Workaround: | Ignore the warnings. This issue is not critical for designs created in VisualApplets. |
| Ticket ID: | – |
| Summary: | Only ASCII Characters Are Supported for *.va File Names |
| Description: | For naming *.va files, only fonts based on ASCII characters can be used; this means that, e.g., Asian, Cyrillic, Greek, or Arabic fonts are not supported for file names. |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
| Summary: | Configuration Is Only Saved For First Instance of VisualApplets |
| Description: | Only the first started instance of VisualApplets is able to save its configuration. All VisualApplets instances that have been started later have only a temporary configuration which will be discarded when the instance is closed. This concerns, e.g., build settings, library settings, system settings, general VisualApplets settings. |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
| Summary: | Design Rules Check Error When M-Type Operators in a Hierarchical Box Are Connected Directly to the Input Port |
| Description: | If you are using hierarchical boxes, in some specific situations, the Design Rules Check may come up with the following error message: "The input XYZ of the operator ABC (hierarchical box) must be connected to an O-type operator, e.g., NOP." The reason is that some M-type operators placed within a hierarchical box cannot be connected to the input port of the hierarchical box directly. This is only true for some specific M-type operators. |
| Workaround: | You can solve this problem (within the hierarchical box) by placing an NOP operator between the input port of the hierarchical box and the input port of the M-type operator. |
| Ticket ID: | – |
| Summary: | Design Rules Check Error When Using the Line-by-Line 1D Simulation Mode |
| Description: | For some designs which passed the Design Rules Check in former versions of VisualApplets, link errors concerning the max. image height may be reported. In particular this may happen when 1D processing is involved and the new line-by-line simulation mode is activated (default). The reason is that in the line-by-line-mode some operators propagate the max. image height of input links in a different way to the output links than before. |
| Workaround: | You can solve this problem by changing to the legacy simulation mode or by adding SetDimension modules for adjusting the max. image height values. |
| Ticket ID: | – |
| Summary: | Increased Operating Time When Using the Line-by-Line 1D Simulation Mode |
| Description: | For some designs the operating time for simulation may be much higher than in former versions of VisualApplets. In particular this may happen when 1D processing is involved, the new line-by-line simulation mode is activated (default), and the design contains many simulation probes. |
| Workaround: | You can solve this problem by changing to the legacy simulation mode or by reducing the number of simulation probes. |
| Ticket ID: | – |
| Summary: | SDK for CXP: Access to the SISO_GenICam Library Have to Be Programmed by the User |
| Description: | SDK for CXP: Accesses to the SISO_GenICam library are not generated automatically, but have to be programmed by the user. |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
| Summary: | Increasing the FPGA Design Clock Frequency May Lead to Slow Builds |
| Description: | Increasing the FPGA design clock frequency may have the result that the build flow takes very long or even fails because timing constraints cannot be met. This strongly depends on the content of the VisualApplets design. |
| Workaround: | No workaround is available. |
| Ticket ID: | 8513 |
| Summary: | Large Images Are Not Displayed in Simulation Probes |
| Description: | When simulation probes contain very large images, VisualApplets may fail to display these images correctly due to memory limitations. In that case, a gray image (i.e. all pixels have the value 205 (0xCD)) is shown. |
| Workaround: | Use smaller images for simulation. |
| Ticket ID: | 6822 |
Library Blob
Operator Blob_Analysis_1D
| Summary: | The Operator Blob_Analysis_1D Sets the Flag object size exceeds maximum Not as Expected |
| Description: | If an object is truncated due to exceeding the maximum size defined by parameter max_object_height_bits, the corresponding flag object size exceeds maximum is set in the truncated object and not in the proceeding object. |
| Workaround: | No workaround is available. |
| Ticket ID: | 9685 |
| Summary: | The Operator Blob_Analysis_1D Does Not Set the Flag label overflow |
| Description: | The flag label overflow indicating that all labels are in use and the current object cannot be tagged, is never set. |
| Workaround: | No workaround is available. |
| Ticket ID: | 9691 |
| Summary: | The Operator Blob_Analysis_1D Allows 20 Labels Less Than Defined per Line |
| Description: | The amount of available labels as defined via the parameter Label_bits is reduced by 20 labels. For example, if Label_bits is set to 5, only 12 (2^5 - 20) labels are available, and not 32 as expected (2^5). |
| Workaround: | No workaround is available. |
| Ticket ID: | 9688 |
| Summary: | The Simulation of The Operator Blob_Analysis_1D is Not Equal to Hardware Behavior |
| Description: | The order of the object feature output might differ in hardware and software. This is so, because the hardware output depends on the timing of the data which cannot be simulated in VisualApplets. Additionally, the FlushI input is asynchronous to the image data input, so completing output frames may not be simulated in a realistic way. |
| Workaround: | No workaround is available. |
| Ticket ID: | 7709 |
Library Color
| Summary: | Some Color Conversions Don't Work As Expected |
| Description: | Operators of the Color library should be used carefully: Some color conversions don't work as a user would assume:
- HSI2RGB converts HSL -> RGB ,
- RGB2YUV converts RGB->YCbCr,
- XYZ2LAB uses constants according to the following definitions: www.easyrgb.com
|
| Workaround: | No workaround is available. |
| Ticket ID: | – |
Operator BAYER5x5Linear
| Summary: | The Resource Estimation in VisualApplets for BAYER5x5Linear Differs From the Estimation in Xilinx |
| Description: | BAYER5x5Linear: In some cases, the resource estimation in VisualApplets for this operator (in dialog FPGA Resource Usage) might differ from the estimation displayed by the Xilinx tools after Place & Route. |
| Workaround: | No workaround is available. |
| Ticket ID: | 6426 |
Library Compression
Operator JPEG_Encoder
| Summary: | The Output Transfer Of the Operator JPEG_Encoder Starts Earlier Than the Actual Image Data Transfer |
| Description: | Operator : To optimize its image throughput rate (band width), the operator outputs the header as soon as header generation is activated - even before image data arrive at the operator's input. This way, the transfer of the header data doesn't interrupt the transfer of image data, as the header is transferred in advance. The drawback of this practice is that the operator's output transfer starts earlier than the actual image data transfer. This may cause irritations under specific circumstances:
If you are using the operator SourceSelector directly after JPEG_Encoder: Operator SourceSelector registers a partly processed frame as soon as it gets the header data. Therefore, if SourceSelector is switched to getting image data from JPEG_Encoder, SourceSelector cannot be switched to any another source as it always detects an unfinished frame. In addition, when header generation is enabled and SourceSelector switches from another source to the JPEG_Encoder channel, the first image is lost. |
| Workaround: | If working on eVA devices, make sure the output is capable to accept data transfer before the sensor transfer is started. |
| Ticket ID: | – |
Library Filter
Operator FIRKernelNxM
| Summary: | Operator FIRKernelNxM May Cause Processing Errors |
| Description: | The operator FIRKernelNxM may cause processing errors in case parameter EdgeHandling is set to constant, the number of columns > 2*parallelism, the number of kernel columns is an even number, and parallelism > 1. The error can be monitored at the left border of an image, where wrong pixel data is used at the kernel positions inside the frame. |
| Workaround: | No workaround is available. |
| Ticket ID: | 2939 |
Operator CLHSSingleCamera
| Summary: | Build Error for Designs With the Operator CLHSSingleCamera for the Platform mE5-MA-VF2 |
| Description: | When you use the camera operator CLHSSingleCamera in designs for the platform mE5-MA-VF2, an internal exception occurs during the build flow. |
| Workaround: | No workaround is available. |
| Ticket ID: | 229896 |
Trigger Operators
| Summary: | Trigger Operators May Cause Spikes at the Trigger Output Line |
| Description: | Trigger operators may cause spikes at the trigger output line during initialization phase when loading the applet onto the frame grabber. |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
Library Memory
Operator ImageBufferMultiRoiDyn
| Summary: | Timing Errors with Small Images |
| Description: | The operator ImageBufferMultiRoiDyn may cause timing errors in case of very small input images. |
| Workaround: | No workaround is available. |
| Ticket ID: | – |
Operator ImageSequence
| Summary: | Build Errors Caused by the Operator ImageSequence |
| Description: | The operator ImageSequence may cause build errors (timing errors). |
| Workaround: | No workaround is available. |
| Ticket ID: | 2422 |
Operator RamLUT
| Summary: | Error When Changing the Platform for a Design with the Operator RamLUT |
| Description: | When you change the platform for a design with a RamLUT operator, the error message "Invalid parameter value: RamDataWidth is not accepted" may occur during the design rules check. This happens, if you are using a module that is using the resource RAM and if the new target platform has a different memory layout than the previous platform. |
| Workaround: | To resolve this, save and reload the design. |
| Ticket ID: | 8708 and 224018 |