Introduction
My approach
Choosing a device
The board
Programmer cable
First power-up
The software
Sample application
Next steps
Other pages of interest

5 sept. 2011: added info on ISE 13.2 + Ubuntu 11.04


Introduction

Here you find documented my first experiments with a CPLD, the Xilinx XC9536. CPLD stands for Complex Programmable Logic Device, and that is a pretty good description. CPLD's have a number of useful properties:

These advantages come at a cost: complexity. While it is simple to connect a few logic gates using 74xxx IC's, a significant barrier has to be overcome to do the same with a CPLD. This barrier consists of required hardware, software & knowledge. However: once this barrier has been overcome, it becomes easier to modify a design. Also one can tackle more complex designs, that would be (near) impossible using standard logic.

There are a small number of companies that produce CPLD's and similar devices. Some of the most popular / well known are Xilinx, Altera and Lattice. My first steps into this world use the Xilinx XC9536. This is a bit older, (relatively) small & cheap device, that works on 5.0V internally. Inputs are 5V-tolerant, and output voltages are selectable between 5.0 and 3.3V levels. The XC9536 is the smallest member of a family of similar devices, that come in various shapes & sizes, with various number of I/O pins. For more info:

My primary goal here was to have a learning experience, to get some hands-on experience with CPLD development, get a feel for the work-flow and the various tools available. For this reason, doing some things 'the hard way' isn't a problem, and may help the learning process. This page serves to document my first steps along the way. Maybe you find it interesting, perhaps it can help you to make your own entrance in this field.

Lots of documentation can be found online. Unfortunately it is often confusing, outdated, and scattered all over the place. If you're an electronics hobbyist wondering whether a CPLD is something for you: I really couldn't tell you, this depends on many factors. Hopefully this page provides a nice overview of what you're getting yourself into. Maybe the info here can help you decide...   :-)

My approach

Getting started with CPLD development may go something like this:

  1. Browse available literature, to decide what family / type of device(s) you'd like to use.
  2. Buy a ready-made development board based on the device (family) you choose.
  3. Buy a programmer to connect the 'target' device with the development system.
  4. Install software to enter designs & program the device with.
  5. Enter a design, in the form of a schematic, or using a hardware description language (Verilog and VHDL are common).
  6. Simulate how that design behaves, and modify where necessary to make it behave as desired.
  7. Adjust settings related to the specific device you're using. For example:
  8. Put the design through a sort of compiler, which may:
  9. If succesful: upload that configuration to the device.
  10. See if it works as expected.
  11. Repeat from step 5.

Each of these steps may involve the use of various hardware & software tools, some of which will be detailed below. In my case: I bought some CPLD's on eBay, put 1 of those on a blank circuit board and built a simple project around that, built a programmer cable myself, and skipped steps 5-8 ...for now. I wasn't even sure things would work, but decided to do it this way to get maximum insight in the low-level details of the process. I triple-checked each step along the way, and got my 1st project to work. Expecting next steps to be just as much work, but getting easier as I learn more...

Choosing a device

I had a slight preference for Xilinx: there is plenty of documentation (including sample projects done by others), a number of low-cost development boards, good bang/buck ratio for devices, and Xilinx appeared a bit more 'student-friendly' than competitors like Altera or Lattice. Also development software can be downloaded for free. Another issue for me was whether I could run development software under Linux (Ubuntu 9.10), but I wasn't 100% sure beforehand whether this would be the case (for any supplier, btw). Lacking experience, this was very subjective and could have gone either way. I do plan to become familiar with some of the other companies' offerings... later.

The XC9500 family seemed like a good choice: can be run on a single 5V supply (nice if you're starting out), interfaces easily with other 5V logic like 74LS- and 74HCT family, in-system programmable, up to 10,000 program/erase cycles, and in a wide variety of package / pin count options. Still in production (so you can be sure that more can be ordered if needed), with faster / lower voltage versions (9500XL / 9500XV) available. And with the smallest family member (XC9536) having a very managable pin count of 44. A nicely priced 20-pack found on eBay closed the deal.

The board

A word of advice: grab a package type that goes into a socket, or has large enough pin spacing (eg. PLCC) to make soldering easy! Or get the device already soldered onto a board... I used the XC9536 in VQFP housing because that's what I got my hands on, and it felt silly to buy more devices (in other package) with 20 of them sitting on the shelf. I had seen a few circuit boards for use with these devices, but couldn't find those when I checked a while later. So I wired up an XC9536 in VQFP package to an experimental circuit board. That was not easy! Pins are spaced at 0.8 mm. interval, pin width and spacing between them is about half that, smaller than the 0.5 mm. wires I used (see photos below). I added rows of IC socket pins for convenient measurements (the black dot near the green wire indicates pin 1), and power supply based on the popular 7805 linear regulator. With plenty decoupling capacitors, a diode to protect against (accidental) reverse polarity, and a LED to indicate power on/off.

Component side Component side close-up Solder side Solder side close-up (click for larger view)

Good things to have on any development board:

This would be a fairly basic minimum - you may be able to find a board that is cheap, but lacks some of these things. Read: the 1st thing you'll do is add those items. So you might as well get that right away... Anything else (USB ports, audio/video connectors, built-in programmer, on-board RAM chips, LCD display, analog I/O, flash card reader, etc, etc) is optional. This will depend on your budget, the application(s) you have in mind, and the degree to which you're willing / able to Do-It-Yourself.

Programmer cable

The Xilinx XC9500 family devices are programmed using a (widely used) serial protocol known as JTAG. This is used for operations like identify device, blank check, program, erase, and various debug functions. The development software runs on an ordinary PC, and a programmer cable is used to control the JTAG pins & upload / download configuration or test data.

Programmer cables exist for connection to parallel, serial (rarely) or USB port, and are usually quite expensive. There are some schematics for older types of cable, and various clones are available from 3rd party vendors. Older cables can be very slow for programming a large CPLD, may not be supported by recent versions of development software, and a parallel port cable is useless if you have don't have a parallel port on your PC. However: none of that is a problem if you do have a parallel port, the software supports the cable, and you're using a small device.

Therefore I built a clone of the Xilinx DLC5 Parallel Cable III. Schematic can be found here (download). It sits in between the PC's parallel port and the device's JTAG pins. It is basically a buffer circuit, which helps to improve signal quality and prevent damage on either side of the connection. It is powered by the development board (this also enables software to detect when that board is powered up), and the connection consists of just 6 wires (ground, 4 JTAG signals, and the supply voltage). The parallel port side can be up to 2 meters long, on the JTAG / device side connections should be kept as short as practical.

Cable Top view Bottom view

The make sure it was working, I actually tested the function of the circuit, before wiring it up to a parallel port connector. That is: I checked that it worked as you might expect from looking at the schematic.

First power-up

Before powering up for the first time, it is essential that power supply connections are correct. You don't want to go through a lot of trouble only to fry the device when you turn it on. Note that PLCC and VQFP versions of the XC9536 have different pin numbering: the VQFP package has pin 1 in a corner (marked by a round dot), while the PLCC package has pin 1 in the middle of a marked side. From there on, pins are numbered counter-clockwise (as usual for IC's). This causes an off-by-6 difference in the numbering of most pins. However: when shown in a drawing, it is clear that the layout of the pins is the same! (probably for easy migration of a design from using PLCC → VQFP parts).

Also it is important that there are no short-circuits between pins: if both are outputs but output a different logic level, the short circuit current can be considerable. For the XC9500 family, short-circuit current between an output and either supply can go up to ~100 mA or more; a continuous short-circuit can easily overheat the device!

In general, it is bad practice to leave unused inputs disconnected, although the XC9536 doesn't seem to be bothered by it (read: show erratic behaviour or extreme power consumption). According to the XC9500 family datasheet, internal pull-up resistors are enabled on I/O pins for an erased device, during power-up, and programming. Read: this may not be true for unused inputs on a programmed device! Therefore it is better for unused pins to either:

The JTAG pins have internal pull-ups, so they are safe to leave disconnected when the device is not being programmed or erased.

You can test whether a pin works as input or output by measuring short-circuit current to both ground and VCC(IO) supplies, through a series resistor (say, ~1 KΩ): an input will show negligable current (zero) in both cases. An input with internal pull-up may show a very small current (µAmps) when connected to ground. A logic 0 output will 'sink' significant current (mAmps) when connected to positive supply, a logic 1 output will 'source' significant current when connected to ground. The amount of current isn't important; just that a significant current comes from the I/O pin, means it is working as an output. This way I determined that the device I used was not erased, before I was able to use its JTAG functions.

The software

Xilinx supports its devices with a whole suite of tools, for the various design & programming tasks. A basic version known as ISE (Integrated Software Environment) WebPACK, can be downloaded for free (as in beer). This software supports most low-end / midrange Xilinx devices, and several programming adapters / cables. Specialized tools, support for high-end devices and advanced features are available to paying customers.

At time of writing, latest version of ISE WebPACK was 11.1, with updates to version 11.5 available. Supported operating systems are Microsoft Windows (XP Professional & Vista) and Linux (Red Hat Enterprise Linux & SUSE Linux Enterprise). Although unsupported, chances are it will run fine on a modern, standards-compliant Linux distribution of your choice. With Ubuntu 9.10, I didn't run into major problems.

Under Linux, the programming tool (iMPACT) needs a special driver to access the parallel port. I installed it first so that any software I tried, would be able to use it. With Ubuntu, installation is fairly straightforward:

  1. Using the system's package manager (Synaptic), install packages "libusb(-0.1-4)" and "libusb-dev". Maybe libusb >=1.0 could be used instead - I didn't try.
  2. The driver also mentions "libftdi-devel", but compiles fine without it. You'll probably want/need this if you use an USB cable, not if you use a parallel cable.
  3. Read instructions and download the driver here.
  4. Unpack the downloaded archive in a temporary directory.
  5. Open a terminal in that directory.
  6. Check the intructions in included "README" on how to compile this library on your own system. A simple 'make' or 'make lib32' should do the trick.
  7. Move the resulting "libusb-driver.so" to a location where it can be found when the system searches for shared libraries. As an obvious choice, I moved it to /usr/local/lib.
  8. Don't forget to set ownership (root) & access rights appropriately (rwxr-xr-x) on "libusb-driver.so" !

Before attempting a big download (and install), I wanted to have some confirmation that the CPLD, programmer cable and connections were actually working. For this purpose I tried a tool named "xc3sprog". The normal download of this tool contains a pre-built binary (source code is also available). With development board connected & powered up, running the tool ("xc3sprog-r401/lin32/xc3sprog") as root without any commandline-parameters, was able to detect both cable (Parallel Cable III) and device used (XC9536). Meaning: cable functioning, connections okay, and device responding / functional (at least to some degree). I can hardly remember a moment where I was so happy to see a simple status message.   :-))

The "xc3sprog" tool has a test-mode which queries the device repeatedly, to see how reliable data transfer is. For long test-runs this would occasionally show an error, but in general the connection seemed stable and reliable. Unfortunately this tool wasn't able to erase or re-program the device, bombing out with an error message about an unsupported version of the device. So (at least for me) it was only useful as a detection / diagnosis tool.

Both "xc3sprog" tool and (later) Xilinx's iMPACT had problems accessing the parallel port when run as a normal user. To minimize these issues I changed ownership of the parallel port (/dev/parport0) to the user running the software (note that this change may be undone by the system after a reboot). Strictly speaking this is a security risk; I wouldn't worry about it unless you have a parallel port ZIP drive connected, loaded with sensitive files. Alternative is to always run such programming tools as root, which is a bad idea (not the entire suite of tools btw.!! you should never need to run these as root).

Downloading ISE WebPACK reguires that you register at the Xilinx website. If this wasn't clear to you before, the registering process shows that Xilinx products & tools are mostly targeted at professionals in a variety of technical fields (aerospace/defense, industrial control, embedded systems, scientific, automotive, etc, etc). However: registering is open to anyone, including students and hobbyists.

The download is a single file which includes Windows & Linux versions, and weighs in at a hefty 2.67 GB (!!). If you're on a slow connection or downloads are unreliable for you, it's best to use a download manager. The website shows an (MD5) checksum, it is highly recommended you use this to verify the file after downloading, before attempting an install. Also, it is possible to run a "Web Install Client" that will download & install only the parts you need, or request a DVD (shipping charges apply).

The install itself is a Windows-style "next" → select install path (default: /opt/Xilinx/11.1) → choose components → "okay" affair, and went without a hitch (to install in /opt, you will need to do this as root). Make sure you have enough diskspace to complete the process! Once installed, a shell script ("settings32.sh") can be used to set things like search paths, and other environment variables. Or you can provide these directly when you run a tool, for example:

   # sudo chown your_name:your_name /dev/parport0
   # source /opt/Xilinx/11.1/settings32.sh
   # LD_PRELOAD=/usr/local/lib/libusb-driver.so impact

(replace "your_name" with username for who runs the software)

That should get Xilinx's programming tool iMPACT running (for which I will not provide a manual here). Note that you will need to obtain a (free) license to use the other tools from Xilinx's ISE WebPACK.

Update: above procedure also works for WebPACK 12.1, on Ubuntu 10.04 (i386 desktop edition). Diskspace used is almost 8 GB (!). Selected components: WebPACK, and cable drivers.

Installation on Debian

Recently I installed a KDE-based Debian stable ("lenny"), upgraded to testing ("squeeze"), and installed ISE WebPACK 12.1 on it. Each of those operations hit a bump somewhere, but I got things working anyway (the length of this section doesn't reflect the effort it took ;-)
The ISE WebPACK 12.1 installer didn't run (at first) because of some weird 'using X server as root user' issue. What finally worked was the same procedure as for Ubuntu, but with following changes:

  1. Package "libusb-0.1-4" came pre-installed on Debian testing, I used KPackage to add "libusb-dev" and "make" (!, basic compiler tool, many Linux distro's will have this installed by default).
  2. Console commands used to run the installer: (screenshot)
       # xhost +local:root   (fixed the root/X server issue)
       # su root             (root privileges needed to install in default "/opt/Xilinx/12.1/ISE_DS/" directory)
       # /path/to/xsetup     (replace "/path/to" with directory where you unpacked the installer)
       # exit                (drop root privileges after installer has finished)
       # xhost -local:root   (optional - maybe this happens automatically, but if not: restore settings as they were)
      
  3. Had to do "modprobe ppdev" in the console (again: as root) to make /dev/parport0 show up... how silly. One might have to change some configuration file(s) to have this done automatically at startup (and give that device node the right permissions).

Re-installing Debian from a testing ISO (weekly build 7-Jun-2010) went much smoother, and issues 2 & 3 were gone. I'll leave those up here in case anyone encounters a similar problem. On some example projects, the synthesis step was tried - with success.

Having gotten various versions of ISE WebPACK to work on different Debian-based distributions, chances are you'll have few problems on systems like Fedora, CentOS or openSUSE, as these are even closer to the distributions on which the Xilinx design tools are supported.

FPGA Editor

Worked through the ISE in-depth tutorial, which helps you become familiar with the various tools, process steps, settings & menu options. In this tutorial you implement a stopwatch that uses the LCD display on a Spartan 3A FPGA board - a modest sized, but non-trivial design. All steps were done successfully, but 1 issue was encountered:

FPGA Editor, a post-synthesis tool that's probably only used by advanced designers, wouldn't run. This program uses another/older GUI toolkit (Open Motif) and was missing some files. Also it seemed to dislike ".0" at the end of DISPLAY environment variable. Fix was easy (and probably applies to other Linux systems):

ISE 13.2 WebPACK on Ubuntu 11.04

This works, but there are some issues. Screenshots: 1 2 3

Sample application

As mentioned under "My approach", I skipped a number of steps for my 1st CPLD project. To be exact, the "enter your design, simulate, adjust settings, and compile into something you can upload to the target device" part. Why? Simple: I just wanted to know the hardware was working, and what software was needed as a minimum to program / erase devices for an already-completed project.

I found a sample project based on Xilinx application note XAPP078, "XC9536 ISP Demo Board", which uses the XC9536 in VQFP package to demonstrate a simple counter with LED outputs. Somebody modified this to use the pinout of XC9536 in PLCC package (sigh...), and placed the ready-to-run result online. I (correctly) hoped that these 2 devices would logically be seen as the same by programming software, and was able to erase, and then program the device on my board with it. iMPACT running in Ubuntu

Next I constructed a low-freqency clock source. By now, what's visible in photos above, has been replaced by a circuit based on the CMOS 4060 - it combines an oscillator section with a divide-by-N binary counter, and this combination is very useful to generate a wide range of different frequency clock signals. Also I modified the oscillator circuit to include a jumper and a switch, allowing me to generate single 0 → 1 or 1 → 0 clock transitions (single-stepping), which can be very useful for debugging purposes.

I used the method explained under "First power-up" to determine which pins had become inputs, and which had become outputs. By 'injecting' a suitable frequency clock signal (through a series resistor), and placing a logic tester on various pins, it was easy to figure out if (and how) the pin functions had changed, compared to the PLCC version of the device. After making a fixed connection for the clock signal & hooking up a row of LEDs, my 1st CPLD project was working...   :-)

The sample project is known as a Johnson counter (actually: a shift register). Upon each 0 → 1 transition of the clock signal (the 'rising edge'), each output (LED) simply copies the state of the previous one. But with a twist: the first in line takes the inverted state of the last one. For N bits, the result is a cycle with 2N states. In effect a simple blinking LED, with the other LEDs acting as a delay line. I've created a short video that shows 3 full cycles. Power consumption is quite modest: around 30~80 mA, depending on number of LEDs that are on. Some of that ~30 mA 'base load' is caused by the 7805 regulator, yellow power LED, and 4060 clock generator. Maximum clock frequency should be around 100 MHz. (not very interesting to watch, with all LEDs constantly on at half brightness).

I've had it running for over a week now... never knew that a few LEDs could be so satisfying to look at...   :-))

Next steps

So... I have made my entrance in the world of programmable logic. Without buying any development board, without buying any programmer cable, without Microsoft Windows as part of the equation... nice. But: with a lot of help (although not in person) from those people before me that have done similar things, uploaded their stuff, and documented their findings. Thank you all !

Where to go from here?

Other pages of interest