Xilinx tools
(C) - André Fachat
In my newest designs (for example the CSA 65816 CPU V2 I started to use programmable logic from Xilinx, especially a CPLD - Complex Programmable Logic Devicei.
When I started to work on that, I had to decide which manufacturer to use. Unfortunately in the area of CPLDs or FPGAs, there are no manufacturer-independent standards in the sense that you could simply replace an FPGA from one manufacturer with one from another manufacturer. Possible manufacturers are Xilinx, Lattice, Atmel, Altera, and possibly others. Therefore I was looking around and, depending on availability (at my favourite parts suppliers) and the licencing and availability of a free development environment, I decided to use the Xilinx versions, as they were still availably in 5V, through-hole parts, and the ISE Webkit was available for free, without any relicensing every year involved (at least from what I understand).
For a deeper introduction look at Hack-a-day CPLD page.
Table of content
The Xilinx devices can be programmed with the ISE Webpack. You need to register with Xilinx though, to be able to download it. The Webpack is available for Windows and Linux.
I wanted to do everything on Linux, so I first installed the Linux version only. I soon found out that to program the devices, the Webpack needed some custom drivers, which did not work under my SuSE Linux 11.2 (current version as I write this). I then also installed the Windows version, and was able to test-program a CPLD device.
In the meantime, however, I have found the libusbdriver code (link below) for Linux that I compiled and installed, and now I can easily programm the devices on Linux and hope not to need Windows again here!
Once you have created the CPLD code, you need to program it into the device. The standard CPLDs provide an in-system-programming port that you can connect to with a 6-pin cable. But where to connect it on the PC side? As usual, there are solutions for the printer port as well as USB. I built myself a "Parallel cable III" clone.
With this cable you are restricted to 200kHz clock while transferring the data, but the cable is cheap (2 74HC125 plus some resistors and capacitors).
The Xilinx tools allow you to use different methods of programming. One is using a schematics editor, to program the device like you would draw a normal schematics. Other possibilities are VHDL and Verilog.
I chose VHDL, as it supposedly has a stricter type system. I want my designs to "fail fast", as the later you find a bug, the higher the cost and a strict type system helps to find problems earlier in the design process.
Once you have your design ready, you want to test it. As VHDL is also designed as a simulation language, with the right tools you can simulate your design. Fortunately there are easy to use, free tools available. I found the GHDL compiler - an extension to the gcc (GNU compiler collection) - together with the GTKWave viewer a very useful combination (sources see links)
In the simulation, you basically do what you do with your normal hardware designs - you
wire it up to a testbench, feed it the right (test) inpt signals, and watch the output or
scope the signals. In VHDL, you thus create a testbench component that includes your CPLD
design as a component. In your testbench you create the test signals using timing statements
like wait for 5 ns to generate the input signals.
Running the simulation then is a matter of compiling the design with for example the ghdl
VHDL compiler, and then running it for a given simulation time. The output is stored in an output file
and contains the values of all the internal signals as defined in your VHDL. Using the GTKWave
viewer you can then view the signals as they are on the time axis, zooming in and out as needed.
See the links for a simple tutorial including a Makefile how to wire the tools together.
I am not (yet) very experienced with simulation. In my PET816 65816 CPU board though I am using a testbench and intensive simulation - which made my scope almost unemployed...
What I also found a great help was to actually emulate the 6502 CPU just as well during the simulation.
One testbench includes a free6502 VHDL core. There it is nice to actually see - in the
GTKWave viewer - the CPU reading the RESET vector, then the first opcode at $FD16 - of course I
simulated the PET kernal in VHDL as well - execute it, fetch the next one and so on...
The main simulation tests I did with an own, fake 6502 core that has the same interface, but
that automatically does a specific sequence of memory accesses. These memory accesses test the
various features of the CPLD in the PET816 board, even including a write to the control register!
Nevertheless there are some lessons learned which I'll describe in the next sections.
Close to hardware...
In the beginning I wrote some simple code that just didn't want to compile. What I finally found out is that I tried to modify a signal in two processes. That does not work, as after all, the CPLD is still some hardware design and the code needs to be compiled into the CPLD.
So to program a CPLD it is important to know that the code basically has to fit into a large array of D-Registers (one half of a 7474 basically) with some kind of GAL-like logic arrays in between. I.e. each signal is basically produced by a D-register with a flank-triggered input and asynchronous set- and reset-inputs. Then it automatically becomes clear that a signal can only depend on a single "flank" of another signal.
When you keep this in mind, you automatically write design the system with a much higher chance that it works :-)
Not everything works right...
With a new technique there comes a learning curve. I found that out when I tried to implement a data bus interface for the 65816 card's control register. The bus is a bidirectional pin, and I could use it as input as well as output in VHDL, I could even set it to high impedance all right, all without any warning from the Webpack (at least none that I found).
However, when I measured the data bus lines, it seemed as if two ICs would be fighting each other. Instead of >3V high level, I had less than one Volt. And the data bus driver as well as the CPLD were slowly getting hotter.
Obviously the CPLD was pulling down the data bus lines all the time, and the high impedance setting didn't have any effect (I controlled the code path with a diag pin and it was ok). When I removed the part that allowed to read the register, the system suddenly started to work!
I don't know yet what was wrong here, if I used the wrong VHDL data type, or the CPLD simply can't do this combination of input and output with high impedance on the same pin.
A diagnostics pin helps...
I found that reserving one pin for diagostics and then in VHDL setting this pin in those parts I wanted to debug helped a lot in finding out what was actually happening in the chip.
Return to Homepage
Last modified: 2010-09-12