Xilinx tools usually use older versions of various libraries. Thus Xilinx requires that users setup an environment by invoking a supplied ‘settings’ file (e.g. settings64.sh). Unfortunately, Xilinx does not sandbox its tool environment resulting in poor interaction with other tools, including AWB and LEAP. For example:

/usr/bin//awb-resolver:
/opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by /usr/bin//awb-resolver)
/usr/bin//awb-resolver:
/opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by /usr/bin//awb-resolver)
/usr/bin//awb-resolver:
/opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version
`GLIBCXX_3.4.9' not found (required by /usr/lib/libawb.so.0)
/usr/bin//awb-resolver:
/opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found (required by /usr/lib/libawb.so.0)
/usr/bin//awb-resolver:
/opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.so.6: version
`GLIBCXX_3.4.15' not found (required by /usr/lib/libawb.so.0)
Can't find /usr/bin//awb-resolver - check your PATH environemt variable

To solve this problem, we recommend properly sandboxing Xilinx executables. We wrap each Xilinx executable in a shell script which invokes the appropriate Xilinx ‘settings’ script.

#!/bin/sh                                                                                                                                                                
source $XILINX/../settings64.sh
program=`basename $0`
exec $XILINX/bin/lin64/${program} "$@"

This wrapper places the ise exectuable in its required environment. Each ISE executable must be so wrapped. We use the XILINX environment variable to steer the script to a particular version of ISE.

#!/bin/sh                                                                                                                                                                
source $VIVADO/settings64.sh
program=`basename $0`
exec $VIVADO/bin/${program} "$@"

Vivado has fewer executables (only vivado and vivado_hls), but still needs to be wrapped. The VIVADO variable is used to steer the script to a particular version of Vivado.

A sample sandbox directory is included below.

The new LEAP 14.08 release supports a hybrid Synplify/Vivado synthesis flow. In some cases, Synplify may terminate with an error message:

fw1811@fw1811:~/workspaces/demo/build/default/traffic_light_vc707_synth_synplify/pm/.xilinx$ grep ‘@E:’ * -r

mk_traffic_light_function_Wrapper/mk_traffic_light_function_Wrapper_cck.srr:E: FX210 |Technology environment variable not set
mk_traffic_light_function_Wrapper/mk_traffic_light_function_Wrapper_cck.srr:E:: Failure during reading EDIF files

mk_traffic_light_function_Wrapper/mk_traffic_light_function_Wrapper.srr:E: FX210 |Technology environment variable not set
mk_traffic_light_function_Wrapper/mk_traffic_light_function_Wrapper.srr:E:: Failure during reading EDIF files

Setting an environment variable XILINX_VIVADO to the Vivado installation directory (in .bashrc or similar) solves the problem, for example:

export XILINX_VIVADO=/usr/local/Xilinx/Vivado/2014.4

In addition to this, Synplify calls “ngc2edif”, a tool that comes with the Vivado installation. Synplify needs to know where ngc2edif lives, so /ids_lite/ISE/bin/lin64 must be added to the PATH environment variable.

In some cases, an old ISE installation can negatively impact the Synplify/Vivado synthesis flow. For example, Synplify may terminate with an error message:

fw1811@fw1811:~/workspaces/demo/build/default/traffic_light_vc707_synth_synplify/pm/.xilinx$ grep ‘@E:’ * -r

mk_platform_platform_Wrapper/mk_platform_platform_Wrapper.srr:@E: CG389 :…/pm/hw/model/pcie_7x_v1_10_pcie_bram_7x.v to undefined module BRAM_TDP_MACRO

Properly sandboxing the ISE installation or ensuring that it does not appear in the PATH environment variable appears to solve this issue.