May 10, 2022

FPGA - using xc3sprog

The xc3sprog program is installed in /usr/local/bin. I can type "xc3sprog -c" and see a long list of "cables" it knows about.

I plug in my Digilent Spartan 3E starter board, and see: 

May 10 17:08:42 trona kernel: usb 3-2: new high-speed USB device number 5 using xhci_hcd
May 10 17:08:42 trona kernel: usb 3-2: New USB device found, idVendor=03fd, idProduct=000d, bcdDevice= 0.00
May 10 17:08:42 trona kernel: usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
This vid:pid of 03fd,000d does not match anything on the list from xc3sprog! Vendor 03fd is Xilinx, which is somewhat comforting, but only two entries in the list with 03fd have the vid/pid of 03fd:0008 (these have names "xpc" and "xpc_internal"). Almost all the rest of the entries are FTDI devices.

Searching on 03fd:000d yields a variety of things, such as:

Apparently the starter board has this $270 JTAG cable built in. Next to the USB connector is a Cy7C68013A chip, which is the Cypress "EZ-USB" chip, and must be the heart of the platform cable. Note that this is the chip that the "fxload" command can fiddle with. This post mentions two LED for USB and indeed there are two on the board next to the USB connector, labeled LD-R and LD-G (so there is a red and green led). It also mentions flashing firmware to the board using fxload and after doing that the vid:pid of 03fd:0008 shows up. But before he did this, he had the Cypress firmware with vid/pid of 04b4:6560, which is a "CY7C65640 USB-2.0 "TetraHub" of all things. 04b4:8613 would be expected for a CY7C68013A development kit.

It looks like 03fd:000d is a newer version of the Xilinx platform loader and is already flashed on my board. It also looks like xc3sprog does not know about this.
There is useful information here:

Note that the first link shows a rule for 03fd:000d as follows: 
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ACTION=="add", ATTRS{idVendor}=="03fd", ATTRS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xusb_emb.hex -D $tempnode"
This runs /sbin/fxload -v -t fx2 -I /opt/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xusb_emb.hex -D $tempnode". Now on my system, the path to this hex file is: 
/u1/Xilinx/14.7/ISE_DS/ISE/bin/lin64/xusb_emb.hex
The "tempnode" variable is set by the udev system in some magic way. From the fxload documentation, the argument to -D is a usbfs path like /proc/bus/usb/004/080.
Right now, "lsusb" shows me: 
Bus 001 Device 004: ID 03fd:000d Xilinx, Inc.
There is no /proc/bus/usb on my system. This is deprecated. These days you go to /sys/bus/usb/devices, or maybe /dev/bus/usb.

If you do go to /sys/bus/usb/devices you are confronted with a bunch of links like 1-0:1.0. How these work is that the "1-" is the bus. Now peek at the kernel messages and see: "usb 1-1.2: new high-speed USB device number 4" This tells us what we want to know, but there is no way to get it from lsusb.

Ugly hacking

I dive into the source for xc3sprog and change the device id for "xpc" cable from 0008 to 000d. This hack is done in ioxpc.cpp. Then I rebuild the software and test. I get an error message "No dongle found", which could mean almost anything. It is entirely possible that xc3sprog is still dealing with /proc/bus/usb rather than /sys/bus/usb -- who knows without a thorough look at the code.

Another XC3sprog

This is another code base, older than xc3sprog. Notice the upper case "XC". This is simpler and only claims to deal with the Spartan starter board, which might eliminate other bells and whistles. It has not been touched in 11 years. It is copyright 2004 by Andrew Rogers and looks like an ancient fork of xc3sprog before it accumulated many features and additions.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org