The applet build step is the final step in the design process of your applets. During the build step, the VisualApplets implementation is translated into the hardware applet (HAP). It is also called synthesis or compilation. The output of the build step is the hardware applet file *.HAP which can be loaded onto the frame grabber hardware.
VisualApplets will call the external tools of the FPGA manufacturer XILINX for HAP generation. Make sure these tools are installed in the right version and VisualApplets is configured accordingly.
![]() |
Xilinx Installation |
---|---|
For a detailed description of the required Xilinx tools, and to learn all about their correct installation, refer to the VisualApplets Installation Guide. |
![]() |
Build Settings for microEnable 5 |
---|---|
When designing for microEnable 5 or LightBridge, make sure you configured VisualApplets accordingly, see section 'Build Settings'. |
The Project Info dock window shows the version of the detected XILINX software (Figure 142, 'Detected Xilinx tools').
Open the Build Hardware Applets dilaog by clicking from the tool bar or by using the shortcut F7.
![]() |
Default Directory for Resulting Hardware Applet |
---|---|
VisualApplets will not ask the user where to store the resulting hardware applet (*.hap file). The file is automatically generated and saved in the directory that is specified under 'System Settings' / Global Build Settings / Generation of Hardware Applets / Path for storage of hardware applets (*.hap). By default, this is the installation directory of VisualApplets. If VisualApplets is installed on your system in a folder that requires administrator rights (e.g., C:\Programs), you have to start VisualApplets with administrator rights in order to use the default path, or to adapt the path setting under under 'System Settings' / Global Build Settings / Generation of Hardware Applets / Path for storage of hardware applets (*.hap). |
The file is copied into the Framegrabber SDK installation directory, if a Framegrabber SDK instance is installed, matched
with the design target runtime and recognized by VisualApplets.
The output filename is equal to the filename of the *.va file, i.e., myDesignName.hap
.
The project name has no influence on the file name of the applet (*.hap file).
To actually generate (build) the hardware applets, VisualApplets uses a whole tool chain that works in the background.
For each hardware platform, VisualApplets provides a default build setup that is optimized for the specific hardware platform.
Based on the hardware platform you selected for your design in the design settings, the according default setup for build is proposed by VisualApplets. This setup cannot be changed by the user, but can be replaced by a user-defined setup.
![]() |
You have to replace the default build setup by own settings if ... |
---|---|
|
![]() |
Recommended Xilinx Tools |
---|---|
See Which Xilinx Toolchain and Version for Which Frame Grabber Platform for detailed information about which Xilinx tool is required to build applets for which hardware platform. mE5 marathon and LightBridge: Although applet build for mE5 marathon and LightBridge is possible with ISE 14.7, Basler recommends to use Xilinx Vivado since applet build (synthesis) with Vivado is much faster for these platforms. |
Each time the program performs the build steps, a certain set of build parameters will be used.
There are several sets of build parameters that come with VisualApplets. You can add additional sets.
For building an applet, one of these sets has to be specified as the “Active configuration”. This configuration will be used and the tool chain will be controlled accordingly.
All setting information is stored in the file “SynthesizeSettings.xml” at your local installation.
![]() |
Activated and Current Parameter Set |
---|---|
To open the Build Settings dialog, click → .The Dialog opens. The activated parameter set displayed:
In the following, we will refer to the parameter set displayed as the "current parameter set". |
The set of parameters itself consists of parameters for starting the external applications (Xilinx tools) that perform certain steps of the workflow, and of parameters for controlling these tools. You can define a certain set to be the default configuration (for starting a build of the current design) by checking “Active configuration”, and you can add a comment to describe the purpose of this specific set.
-
To open the Build Settings dialog, click menu
→ .The Dialog opens. The activated parameter set is displayed.
Before Adding the First Alternative Parameter Set As long as no additional parameter set for the target hardware of your design has been created, the default build settings are displayed.
You cannot make any changes to these default settings, therefore, all input fields are deactivated.
You also cannot uncheck “Active configuration” as there is no alternative to the default yet.
-
Click
to create a new set of parameters.You will be asked for hardware platform information. You can specify here which parameter set you want to load as a basis for creating your own parameter set. In most cases, it is quite sensible to select here the target hardware of your design.
-
Click
.Now, you can edit the first fields.
-
Name: Give a name to your new set of properties for identification. This name will show up in the configuration dialog and in the build protocols.
-
Active configuration: If you want to use this set of parameters when building your applet, check the box Active Configuration.
Active Configuration The set of parameters you define as Active configuration will be used as often as you execute a build.
When you change the hardware platform you selected as target hardware platform of the design: Define new build settings for this new platform.
-
Precondition Check: In default mode, the Precondition Check is activated. The Precondition Check verifies that the FPGA type on the target hardware of your design is supported by your Xilinx tool chain. In addition, in all designs for mE5 or LightBridge platforms: When this check box is activated, the information in operator AppletProperties is updated at each build, namely the fields BuildTime and AppletUid. Therefore, after a build has been completed, the design is in "unsaved" mode, since the parameter values in the operator AppletProperties have been changed during build.
Avoiding the Update of AppletProperties Under specific circumstances you might not want to update the AppletProperties operator by a build. In this case, simply de-activate the check box Preconditions Check.
-
Xilinx ISE/Xilinx Vivado: Select the Xilinx tool chain you are going to use. Vivado is supported by all marathon and LightBridge platforms. If Vivado is not supported by the target hardware of the open design, this is stated directly in the GUI:
-
Build Environment:
-
When using a newer Xilinx tool (i.e., when developing with Xilinx Vivado or with Xilinx ISE in a version higher than 9.2):
-
De-activate the “Use system environment” checkbox, and
-
from your file system, select the Xilinx settings batch file that sets the environment to launch the external tools.
Please follow the Xilinx documentation to make the best choice.
You find the batch file in the Xilinx installation folder:
-
ISE: \Xilinx\14.7\ISE_DS\settings64.bat.
-
Vivado: \Xilinx\Vivado\2020.2\settings64.bat.
Basler recommends to use the 64-bit Windows operating system when developing applets for microEnable 5 platforms. Make sure you select the batch file that matches the operating system you are using, e.g., "settings64.bat" which is the file for the 64-bit Windows OP.
-
-
If you use an older Xilinx ISE version (version 9.2 or older) and all environment variables are set at the operating system, activate the “Use system environment” checkbox.
-
-
Build Flow: Activate all options under Build Flow. Normally, all steps should be activated.
Basler recommends to set the system under Multi place and route to 20 iterations.
Keep the Command Mode at Use platform default value.
-
Applet Generation: Activate Applet Generation.
-
Comment: Enter a comment that describes the set of parameters you just created. The entries you make here have no effect on the actual build process.
-
Click the OK button.
Example: When developing for microEnable 5 or LightBridge, the following parameter values need to be set:
![]() |
Disabling Build Flow Steps |
---|---|
Per default, all build flow steps (translation, mapping, ...) are activated: With the Expert license or the VisualApplets 4 license you can de-select individual steps. However, the build steps depend on each other. They are listed in the order of their dependence:
However, a previous step doesn't need to be executed within the same build run. It might as well have been executed in an earlier build run. As long as the files (trace files) that have been generated during an earlier build run are still available, it is possible to deactivate steps that come earlier in the "Build Flow" list and to activate steps that come later in the list. To keep trace files of earlier build runs: Go to menu → → . Under Build Trace Files, activate Keep build trace files. Deactivate Compress build trace files.If you keep the build trace files, and you have carried out all previous build flow steps once before, you can also activate only subsequent steps, e.g.: |
![]() |
Command Mode Options |
---|---|
With the Expert license or the VisualApplets 4 license you can change the . To change the , go to Command Mode at the right upper corner of the Build Flow area.In the list, you have three different options:
---------- Use platform default value (Default): If you keep or select this option, VisualApplets displays the default values recommended for the hardware platform you specified as target platform for the open design. VisualApplets also uses these default values when running the Xilinx tools (i.e., when the actual applet is build (synthesized) out of the open design). Since default sets cannot be modified, it is not possible to edit the Arguments fields in the Use platform default value mode. Append to platform default value: If you select this option, you can add information for the Mapping and Place and route tools to the basic arguments provided by VisualApplets. During build, VisualApplets adds the parameters you defined in the Arguments fields to the platform default values when calling the tool. This setting is for experienced users only. Overwrite platform default value: If you select this option, VisualApplets displays the default arguments for Mapping and Place and route for the target hardware platform you selected directly after creating the new applet set. You can define (overwrite) the Mapping and Place and route arguments stated here. VisualApplets now uses only the parameters you specify in these Arguments fields when calling the tools. This setting is for experienced users only. |
In the Build Settings window, you have some options for handling parameter sets:
Clicking on
-
Add creates a new parameter set which you can modify as you want (based on the hardware platform you select).
-
Copy copies the parameters of the current set, creates a new set and pastes the parameters of the copied set into the new set.
-
Import allows to import a certain set of parameters into the current installation of VisualApplets.
-
Export selected saves the current parameter set to a file. The file can be used for transporting the data to a different PC or installation or for backup reasons. A dialog is displayed where you can specify a file name and location.
-
Delete deletes the current set of parameters.
For mE 5 ironman, mE5 marathon and LightBridge, the checkbox Precondition Check offers a specific function:
-
If Precondition Check is activated, at each start of synthesis (build) the entries for BuildTime and AppletUid are updated. If you want to start a complete build (from netlist generation through to applet generation) you need to activate Precondition Check. Otherwise, later on (when using the applet on the frame grabber) the loaded applet cannot be reliably validated by the runtime environment.
-
Specific option: If you have already completely built an applet, but decide you need another *.hap file for another target operating system: You can build a new OS-specific hap file out of the complete build to make your design usable on other target operating systems (i.e., for another target runtime). Proceed as follows:
-
In menu Settings, select System Settings.
-
In the window that opens, select category Global Build.
-
Here, under Build Trace Files, activate the option Keep build trace files and specify a path.
-
Go to menu Settings, menu item Build Settings.
-
Deactivate option Precondition Check.
-
Deactivate all other options under Xilinx Build Flow.
-
Activate Applet Generation.
-
Under Defaults, activate Active Configuration.
-
Start the build of the OS specific *.hap file.
Especially with complex designs, this option allows you to save time.
-
In VisualApplets, multiple build settings can be created in the in the Build Settings dialog which are stored in the application.
In the Build Hardware Applets dialog under Xilinx configuration, you can select one of the build settings you defined in the in the Build Settings dialog. The Build configuration you select here will be used for the build you are going to start. Default value is the configuration you specified as Active configuration in the Build Settings dialog.
-
Under Xilinx configuration, select the build configuration you want to use for the build.
In the same Build Hardware Applets dialog, you can specify the required target runtimes. By default, the target runtime of the design file is selected. (See 'Target Runtime') However, sometimes the applet will be used on multiple target runtimes. In this case, multiple target runtimes can be selected as can be seen in the next figure. VisualAppelts will generate a HAP file for all selected target runtimes.
For the target runtime you defined the design file, the output file is located in the specified directory as described above. The file name of this output file is the same as the name of the *.va design file, only with the *.hap extention. The file is copied into the Framegrabber SDK installation, if the Framegrabber SDK is installed.
All additional output files: VisualApplets will add target runtime information to the file name of all additional output files, like “_Linux_AMD64”, “_Linux_IA32”, etc. These additional HAP files will NOT be copied into the Framegrabber SDK installation directory.
![]() |
Repacking the *.hap File for Other Target Runtimes at a Later Stage |
---|---|
You can easily create a new *.hap file for an additional target runtime at a later stage without starting the whole build process again. This may save you a lot of time as the repacking only takes some minuts. For details on how to repack a *.hap File for additional target runtimes, see section 'Repacking the *.hap File for Other Operating Systems at a Later Stage'. |
The platforms imaFlex CXP-12 Quad and imaFlex CXP-12 Penta have one additional build setting:
.This setting has an effect on the build velocity and device ressources.
:
-
Builds your design in approximately one hour.
-
Does provide a ressource estimation after the build.
-
Does NOT work, if you have operators of the Blob library in your design. In this case, the build will be aborted with an error message.
:
-
Builds your design in approximately three hours.
-
The built design uses less ressources.
-
Does NOT provide a ressource estimation after the build.
-
Works for all operators.
Basler recommends to use always the
netlist synthesis engine.The build process will always execute design rules checks level 1 and level 2. If one of the fails, the build process is aborted. Check 'Design Rules Check' for more information on the design rules checks.
Moreover, the build process can cause several further errors. The most likely errors is a resource overmap or timing error. If an applet contains to much logic elements, the XILINX tools cannot map all required elements to the physically available elements. In the case of a resource overmap, your design has to be optimized to fit into the FPGA.
In case of a timing error, the XILINX tools cannot route all signals within the allowed constraints. This mostly happens if almost all logic resources are used. The design has to be optimized to use less resources in this case. Designs which have a timing error can still be completed. Keep in mind that a hardware applet which did not meet timing might not work correct. It might result in time-outs, failing data or other unexpected behaviors if used. Therefore, the use of a non-timing matched applet should only be used with care and is at the user's own risk. If the required resources of your design are far less than 100% and you still get timing errors, contact the Basler Support.
Other errors can be caused by an incorrect XILINX installation or disk volume access permissions.
Note that the build process might require some hours to be completed.
The usage and run of a hardware applet file (HAP) is described in the Framegrabber SDK documentation. The SDK generator of VisualApplets can help with the first steps of running an applet. See 'Framegrabber SDK' for more information.
microDisplay is part of the Framegrabber SDK. It is a tool for first tests of the generated applets. If the Framegrabber SDK is installed, microDisplay can directly be opened from VisualApplets by clicking on F5 ). Alternatively, you can also use the icon microDisplay from the Build icon bar.
→ (
You can create additional *.hap
files
out of an already existing *.hap
file.
This is especially helpful if you want to use an applet on additional
operating systems you did not specify before the first build.
You do not need to start the whole build process again. This saves you a lot of time. The repacking only takes some minutes. Only the operating system specific parts of the original *.hap file are replaced by VisualApplets during the repacking process.
![]() |
Pre-Conditions |
---|---|
To repack an existing Otherwise, you will get an according error message. |
To create additional *.hap
files for additional operating systems:
-
From the menu, select
→ .The Repacking Hardware Applet Files window opens:
-
Select the original *.hap file using the browse button.
VisualApplet immeadiately checks if the original *.hap file was created with the same version of VisualApplets (2.2 or higher) you are using now (which is a precondition for the repacking process, see above).
If the VisualApplets version doesn't match, an according error message is displayed.
-
If everything is fine, click the Next button.
-
Under Runtime, select the target runtime (i.e., target operating system) you want to create the new *.hap file for.
VisualApplets offers a file name for the new *.hap file.
-
Adapt the output location and the file name for the new *.hap file to your needs.
-
Click Next.
VisualApplets displays all settings you have specified for the repacking:
If you need to adapt your settings, you can use the Back button.
-
Click Finish to start the repacking process.
After successful repacking, you get an according message: