Sorry, you need to enable JavaScript to visit this website.

ISE 14.2 Bug Reports

Zedboard forums is currently read-only while it under goes maintenance.

6 posts / 0 new
ISE 14.2 Bug Reports


Yesterday I installed ISE 14.1 from the DVD and after no success with getting the ZedBoard to work I downloaded ISE 14.2 and installed that. I had to fight a little to get everything running. To help others getting their installation working and to supply Xilinx with some bug reports, I'll post my experience here.

I'm working on Debian (sid, fully updated) on a 64 bit Intel Core-i7. So these problems mostly apply for this combination.

1) Mentor CodeSourcery

During the ISE installation, it also (silently) installs Mentor CodeSourcery to /opt/Xilinx/14.2/ISE_DS/EDK/gnu/arm/lin64, which contains GCC and GDB for the ARM architecture. Unfortunately, no errors are given to the user if problems occured during installation.

Their installer does not like "dash" as the default shell /bin/sh, but does not complain! When executing its installer by hand, they suggest to reconfigure the dash package to not be the default shell.

# dpkg-reconfigure -plow dash

and say [No] when asked to use dash for /bin/sh.

2) User Permissions

When starting PlanAhead for the first time after installation as a normal user (not root), a little window complains that it cannot write to /opt/Xilinx/14.2/ISE_DS/.xinstall/ Why should it write there?

3) Locale

PlanAhead don't like German locale due to a bug using ',' instead of '.' as decimal point when displaying schematics.

$ unset LANG

4) PlanAhead 100% CPU Usage

While XPS is running and PlanAhead waits for it to quit, PlanAhead requires 100% CPU. Interestingly enough, this only happens after the 2nd time XPS is executed (or so).
1) Why does PlanAhead need to be "locked" while XPS runs?
2) Why use 100% CPU?

5) PlanAhead VHDL Editor

When copy-pasting code, sometimes its common indentation is changed, but this doesn't fit to the surrounding blocks.

When saving a VHDL file, the whole window is disabled (grayed out) for 1-2 seconds (on a quite fast PC!). This seems to be the auto-update of hierarchy and stuff. Why does this lock the whole window? And why does this consume so much CPU?

6) Browser doesn't work when started from SDK

When clicking on links (e.g. in the system.mss file), the console where "xsdk" was started says:
epiphany-browser: /opt/Xilinx/14.2/ISE_DS/common/lib/lin64/ version `GLIBCXX_3.4.9' not found (required by /usr/lib/
epiphany-browser: /opt/Xilinx/14.2/ISE_DS/common/lib/lin64/ version `GLIBCXX_3.4.15' not found (required by /usr/lib/

strace reveals, that clicking a link searches MIME->App. mappings (e.g. /home/hansi/.local/share/applications/mimeapps.list), which further finds /usr/share/applications/epiphany.desktop and (after some playing around with DBus) executes epiphany-browser, which is searched in $PATH.

Solution: Add a script /opt/Xilinx/14.2/ISE_DS/ISE/bin/lin64/epiphany-browser which unsets LD_LIBRARY_PATH before launching the browser.
# Execute Epiphany Browser with unset LD_LIBRARY_PATH

exec /usr/bin/epiphany-browser "$@"

7) GMake

The SDK build process requires "gmake":

$ ln -s /usr/bin/make /home/hansi/bin/gmake

8) JTAG via USB

The JTAG USB device doesn't allow a normal user (other than root) to access it. The FTDI FT232H enumerates as
0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
for which automatically the module "ftdi_sio" installs as ttyUSB0 serial driver.

The /etc/udev/rules.d/52-digilent-usb.rules matches to all devices with idVendor=1443 and 0403 and launches /usr/local/sbin/dftdrvdtch to detach the fdti_sio driver. Actually, it should also set the mode to "666", but /dev/bus/usb/001/034 is still only rw-rw-r-T.

The problem is that /lib/udev/rules.d/91-permissions.rules overrides the mode with "664".

Solution: Rename 52-digilent-usb.rules to 92-digilent-usb.rules.

9) The Digilent JTAG cable makes problems with XMD

The Xilinx Microprocessor Debugger (XMD) Engine makes a SIGSEGV. GDB showed that this happens in /usr/local/lib64/digilent/adept/ which is the Digilent Adept driver. The very same problem happens with iMPACT, for which I found the following forum discussion.

The suggested solution with worked for me. Unfortunately, the SDK cannot be modified to do this, therefore we have to replace the original "xmd" executable by a script.

cd /opt/Xilinx/14.2/ISE_DS/EDK/bin/lin64
mv xmd xmd-xilinx
mv unwrapped/xmd unwrapped/xmd-xilinx

Create new file "xmd" with the content:

# Execute XMD with LD_PRELOAD
# /opt/Xilinx/14.2/ISE_DS/EDK/bin/lin64/xmd-xilinx "$@"

Then make it executable

chmod a+x xmd

I also installed the newest Adept 2.10.2 runtime from Digilent,66,828&Prod=ADEPT2
which alone didn't solve the problem.

10) SDK Debugging hangs

Still, debugging with SDK didn't work. The startup window ("Launching Delegate" or similar) still kept hanging.

Some debugging revealed that XDM is executed as
xmd -nx -json -ipcport 2350
(i.e., no xmd.init, use JSON as protocol, and communicate via TCP port 2350). Using "tcpdump" I found the following conversation taking place:

xload hw /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/proc_module_hw_platform/system.xml
xconnect arm hw -debugdevice cpunr 1 devicenr 1
set_cur_target 64
targets 64
xdebugconfig 64 -reset_on_run processor enable
source /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/proc_module_hw_platform/ps7_init.tcl
xzynqresetstatus 64
xdownload 64 /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xelf_verify 64 -random /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xsafemode 64 -elf /home/hansi/Projekte/ZedBoard/zed_first/zed_first.sdk/SDK/SDK_Export/hello_world_0/Debug/hello_world_0.elf
xsafemode 64 on

where the last command issues a sigsegv. GDB says where this happens:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004d44fb in CortexA9DebugManager::printExceptions(int) ()
(gdb) bt
#0 0x00000000004d44fb in CortexA9DebugManager::printExceptions(int) ()
#1 0x00000000004bd79f in tclSafeMode ()

When these commands are executed by hand, the following messages are displayed before the sigsegv:

WARNING: It is recommended that you load the Hardware Specification file at the begining of XMD session: e.g., xload hw system.xml.
WARNING: All enabled exceptions will be trapped. If you need more control over which exception to trap, set all exception handler at writable addresses with command 'safemode -config <ID> <Address>'

While this is clearly a bug in XMD, the solution was quite simple: I deactivated the Safe Mode which I've previously enabled in the Debug Configurations -> Debugger Options tab.

11) XMD
As shown above, XMD provides lots of "x*" commands which are not documented in "help". The special (secret?) command "xhelp" reveals a list of commands.

Secondly, the "xdownload" command used by SDK requires much more time than the (equivalent?) "dow" command to download the ELF file. GDB shows thousands of newly created threads which are destroyed immediately during the long delay of "xdownload".



Thanks for documenting these issues.  It would be great if you could report these to Xilinx through their WebCase portal --

I registered for a WebCase

I registered for a WebCase account, but it was denied a few minutes ago, presumably for using a German free-mail account. Although I'm a faculty member of Vienna University of Technology, I investigated the ZedBoard in my spare time. My contribution to this forum with bug reports (usually highly appreciated in open-source communities) as well as solutions (hopefully useful for other Xilinx customers) also was a private effort. Therefore I ask you or a Xilinx forum moderator to forward these bug reports to the responsible product manager and the programmers.


Bug reports for non-supported Linux distros

I tried to report an issue with ISE on Fedora 17 and had the report closed because F17 was not a supported distro for ISE.

I ran into the problem where the arm toolchain fails to install, unless you install the 32 bit glibc package on a 64 bit distro. An avnet FAE asked me for an install log, maybe he can make some progress with this issue.

In debug mode

In debug mode how to check the break points address


To unset LD_LIBRARY_PATH I chose to define a variable called LD_LIBRARY_PATH within my sdk.
Under project-properties->C/C++ Build->Environment I added this variable with the value <UNDEFINED> and applied my change with "Append variables to native environment".
With value