Xilinx USB with a modern distro

So, you got yourself a Xilinx FPGA-based development board, installed all the design software ( ISE 12.1 – more than 10 GiB! ), run Impact (the all-visual programming tool), tried to do a boundary scan… and watched a long pile of windrvr6 kernel module related error messages, only to find it did not found your USB cable.

Don’t worry. It’s not exactly “plug and play” on Windows either – the x64 editions also require you to drop to a shell.

Long story short: Xilinx used to distribute a Jungo WinDriver based kernel module for use with their platform cables. Of course, keeping a propietary kernel module in sync with the kernel is a complete nightmare, and they weren’t very good at it either. Fortunately, someone created a userspace wrapper around Impact to libusb. More recent versions of ISE though have now integrated direct access to libusb, so there’s no need to use neither the kernel module nor the wrapper now. In fact, using the kernel module will be next to impossible – even though that’s what the Xilinx ISE installer means when you check the “Install USB drivers” option during setup.

But not even the Linux userspace is stable; so even the fully userspace strategy ISE 12 used was already outdated the moment it was released. Fortunately, just two things have been broken so far: udev rules files syntax changed, and libusb changed its interface (and most distributions no longer ship the older, pre 1.0 version).

Fortunately, both issues should be easily solved.

udev is used by ISE to load the appropriate firmware to the USB device as soon as it is seen by the system, AND set up appropriate permissions for it. This is done with what’s called a rules file, which is parsed by udev and used to decide what to do when a new device appears. Note that everything here requires root.

  1. ISE uses the fxload program to load firmware. You must ensure you have it installed. Either apt-get install it, or use your distributions preferred method to install it.

  2. Download xusbdfwu.rules and put it into /etc/udev/rules.d/. This is modified from the rules files ISE ships with; it requires udev with extras (usb_id); you most probably have it installed.

  3. Time to copy the firmware files from the folder you installed ISE to /usr/share. Assuming you installed ISE to /opt/xilinx, do:

     cp -v /opt/xilinx/ISE_DS/common/bin/lin/xusb*.hex /usr/share/
  4. Either reboot your machine, or run udevadm control --reload-rules.

If you plug the board into an USB port, lsusb will list an entry similar to the following one:

Bus 002 Device 006: ID 03fd:0008 Xilinx, Inc.

The underlined part is the USB’s device ID. If it’s anything other than 0007, 0009, 000d, 000f, 0013 and 0015, it means the firmware was loaded successfully. Otherwise, your board/cable/programmer is still expecting firmware. Check the above steps and your system logs for clues.

Now onto libusb. Basically, you need libusb 0.1. Debian Lenny’s version will work. Probably, any other distro’s binary will work, as long as it is libusb 0.1.12. Newer 1.0 versions don’t work.

  1. I’m mirroring the Debian’s binary for you. Here’s the 32 bit version, which you have to copy into /opt/xilinx/ISE_DS/ISE/lib/lin/libusb-0.1.so.4.4.4, and here’s the 64 bit version, which you have to copy into /opt/xilinx/ISE_DS/ISE/lib/lin64/libusb-0.1.so.4.4.4 .

  2. Important: IMPACT will look for a file named libusb.so , so even if your distribution has libusb-0.1, chances are it’s not shipping a libusb.so file but a libusb-0.1.so, and it’s not creating the libusb.so symlink. On Debian, you need to apt-get install libusb-dev package. On other distros, you need to create the symlink manually:

     cd /opt/xilinx/ISE_DS/ISE/lib/lin/
     ln -s libusb-0.1.so.4.4.4 libusb.so

    64 bits version:

     cd /opt/xilinx/ISE_DS/ISE/lib/lin64/
     ln -s libusb-0.1.so.4.4.4 libusb.so

    This assumes you copied libusb-0.1.so.4.4.4 to /opt/xilinx/ISE_DS/ISE/lib/lin/ as per step 1.

Now, launch IMPACT, start a Boundary Scan and try to do a “Cable Auto Setup”. If it works, congratulations!

If it didn’t work, carefully check both the IMPACT log and its standard output (i.e. the messages on the console where you opened IMPACT from) – it might have interesting messages that might clue you into the right direction.