Env Specs: ubuntu (lsb_release -a: 16.04.5 LTS / xenial as VMWare Fusion 10.1.2 virtual machine on Mac OS X Mojave 10.14.2), urjtag (2018.09 from sourceforge, just use tar -xf urjtag-201809.tar.xz btw), ISE webpack (14.7 sustaining phase only of software life cycle btw), libftdi installed, not ftd2x

Sketched up quick notes about testing out a CPLD solution to merge several blocks of logic (*595’s, *597’s) in a recent rapid prototype concept eval/demo project, using some open hardware maker boards we already had, but hadn’t tested yet. Heavy emphasis on testing hardware, tools, and resources from Dangerous Prototypes (DP). As of this writing, the XC9572XL (Plan A) and related family are a bit old, as are the hardware and resources referenced in here, but still a valid path for our purposes because the Plan A chip is still available, not EOL, and fully capable of handling the minimal amount of logic integration we need. It is 5V tolerant, and can run from a 3.3V rail, which are both important points in minimizing complexity for our needs on this project.

After building up a tool chain, we found (so far) that the XC9752XL wouldn’t work reliably in this tool chain (issue with playing the .svf file into the chip via urjtag), although it is still a preferred chip for the reasons noted above. An unanswered forum post from a few years ago at urjtag’s discussion page (from Ian of DP no less) seems to confirm the same. Several attempts at work-arounds and several verifications (including using a driver from git.zerfleddert.de for direct connection from within ISE) led to the next point, moving along (to maintain some schedule and agility here)…

So, in the spirit of “moving along…” and leveraging the momentum we already had in the tool chain, we swapped the XC9752XL for the XC2C62A (Xilinx CoolRunner II) mini dev board and poof, good to go. Almost poof (in a good way, poof, not like poof up in smoke) anyway – a few more steps to pull some samples files and also to retarget some ISE schematics and chip pin constraint files (.ucf) and then regenerate the svf, and a successful playback/upload to the Plan B CPLD.

Summary and notes of some steps below. This is not intended to be an exhausting tutorial — those resources are out there (see links at the bottom). Just some specific notes here that were relevant.

Step 1. Build urjtag and test connection to the BB

Little gotchas and work-arounds:

Compiling urjtag:
issue with unrecognized mprf_z_sub during 
:./configure
: due to library paths left over from the ISE webpack install.  Solution 
:unset LD_LIBRARY_PATH
 --- wants python2.7, so 
:sudo apt-get install python-dev (for python.h header requested during make) --- after sudo make install 
run :sudo ldconfig so (ur)jtag sees a library it needs --- then 
run :jtag to test --- run lsusb to verify connected device and PID and VID --- 
issue with Error: Illegal State: Fewer bytes written than requested --- something glitchy --- in one case unplugging/replugging the USB device(s) and restarting jtag worked while in another (old school) restarting the OS worked --- haven't looked into root cause yet --- moving along ...
:jtag  
jtag>cable ft2232 pid=0x6010 vid=0x0403 interface=1 # this is the FTDI JTAG B port
jtag>Connected to libftdi driver.
# interface 1 is the Bus Blaster 2.5's on-board CPLD while interface 0 goes to any connected JTAG device, once that is set up
jtag>detect
# Now we get correct output from the detect command, indicating the on-board xc2c32a-vq44 and yes now urjtag includes the definition for this chip as shown in an entry for the Filename
# Prior an executable, without building, we were getting crash after detect command for the interface 1, even though we were trying to add the bsdl file to the path for the urjtag
# Notice that on detect for interface=0, we get: warning: TDO seems to be stuck at 1 ... that is because we need to tell urjtag to load the jtagkey driver role when talking to the other chip (the 2nd channel on the ftdi), so the command is:
jtag>cable jtagkey pid=0x6010 vid=0x0403 interface=0 
# The "jtagkey" is now important here so that urjtag properly talks JTAG to the target on the mini dev satellite board
# This is really after the next step ... but called out here to differentiate calling cable ft2232... versus calling cable jtagkey...

Step 2. Download JTAG tool emulation buffer code into the on-board CPLD

# github => for emulating a JTAGkey could try one of the BBv2-JTAGkey svf files --- 
:cp BBv2-JTAGkey-v1.4-VHDL.svf ~/CPLD-Testing/bbv2.svf
:sudo jtag
jtag>cable ft2232 (etc) interface=1 #on-board
jtag>detect
jtag>svf /path/to/file/bbv2.svf stop progress
# So, what we're doing here is: Using the FTDI JTAG B (interface=1) port to talk JTAG to the CPLD on the BB itself, and then programming that CPLD to act like a jtagkey type of JTAG programmer/debugger and talk to a target chip connected to its target 2x10 header.  So software talking to the FTDI JTAG A (interface=0) port now thinks it's talking to a jtagkey and can program use target device via JTAG.

Step 3. Test Connection to the Attached Target Mini Satellite XC9572XL Dev Board

:jtag
jtag>cable jtagkey pid=0x6010 vid=0x0403 interface=0
jtag>detect
# Initially we get a notice that the stepping is not known and so no Filename is selected
jtag>quit

# So we edit the STEPPINGS file because the stepping here (0101) is actually not yet included in the STEPPINGS file that maps the stepping in the model number to a device
:sudo nano /usr/local/share/urjtag/xilinx/xc9572xl/STEPPINGS
# add to the file:
0101   xc9572xl_vq44   5
# and save because this is the vq44 package

:jtag
jtag> (redo the cable and detect commands above)
# Now we see the correct file selected for this device for bdsl

Step 4: Load something onto the target (XC9572XL) CPLD!

# We had compiled and exported an svf before from ISE webpack
# It's called: led1.svf
jtag> (already did cable and detect commands for the target)
jtag> svf outfile.svf stop progress 
# error regarding one of the SDR (serial data read) commands early in the SVF file -- something not working reading back correctly 
# same with a prepared tutorial file svf content
# not the same directly from within ISE (things got muddy and inconsistent and glitchy quickly... but we were able to program from within ISE using the open source driver from zerfleddert... and yadayada)
# much digging, trying, testing ... moving along ...

Step 4B: Err… Try a new XC2C64A (CoolRunner II) target CPLD!

jtag> (already did cable and detect commands for the target = using jtagkey and interface=0)
jtag> svf outfile.svf stop progress
jtag><paraphrase>everything matches, good playback/programming</paraphrase>

Issues and Debugging

Re-writing/overwriting .svf files from iMPACT and doesn't look like new code is getting uploaded to the target - rather same code as prior?  Try: iMPACT=> Output => Stop writing to SVF file (this seems to have worked to allow urjtag to grab the new file and send this to the target ... whereas before, despite writing the new file in iMPACT, the behavior of the target seemed the same.

Resources:

See wrong stuff? Errors? Drop a line. Please overlook typos etc. in these quick snapshot sketch types of posts..