Nuts and Volts - February 2009

matches the JTAG dongle that you buy. JTAG drivers are more standard and easier to install on Windows, and for this reason many would-be Linux FPGA developers move to Windows for FPGA development. I know one Linux user who does all of his development on Linux and then copies his files to Windows for the JTAG downloads.

The Xilinx command to manage JTAG devices and downloads is named impact. It is a command line interpreter similar to xst, and its internal commands and options are described in full in Appendix C of the iMPACT User Guide at

http://tool box.xilinx.com/docsan/xilinx4/data/ docs/pac/ preface.html Xilinx compatible JTAG dongles are available from several commercial sources, and Appendix B of the iMPACT User Guide even has a schematic of a simple JTAG dongle that attaches to a legacy parallel port.

The sub-commands to use inside iMPACT can vary a great deal depending on the type of FPGA board that you are using. I've found that the easiest way to deal with impact is to run ISE and invoke the GUI interface to impact the first time I download to a board, and then extract the impact sub-commands from the _impact.log file.

Using this technique on the SparkFun Spartan 3E Breakout and Development Board gives an iMPACT command of impact -batch impact.bat where the batch file is:

Note the addDevice -p 1 sub-command in the above batch file. JTAG devices are usually arranged as a string of devices and the addDevice sub-command specifies which device in the chain of devices to program or examine. Some manufacturers (such as Digilent) prefer PROMs that can be programmed directly from JTAG. Other manufacturers (such as SparkFun) have you use JTAG to load an FPGA program that then reads from a serial port, burning the received bytes into the PROM. The Baseboard-2 is meant to be connected to a PC, and since a download to the Baseboard-2 takes less than 100 milliseconds, it hardly seemed necessary to add a PROM and force the user into the cost and driver issues associated with JTAG.

Conclusions and Next Steps

In this article, I focused on two

setMode -ss
setMode -sm
setMode -hw140
setMode -spi
setMode -acecf
setMode -acempm
setMode -pff
setMode -bs
setCable -p auto
addDevice -p 1 -file
counter.bit
Program -p 1 -
defaultVersion 0
Quit

things: expressing your design as text files and using just a few standard commands to compile and download your design. Having your design in text files will make it easier for you to track changes and will make it easier for you to add version control for your projects.

Using command line tools can be faster and is a nice way to better understand the steps to convert a design from Verilog to a bitstream file. Even if you switch to a GUI-based approach later, at least you now have more appreciation for what is actually going on.

You may have noticed another purpose in this article. It is an attempt to get a working Verilog program is as few steps as possible.

I meant this article to be something of a "Hello, World!" program for Verilog. The next steps are, of course, up to you. Here, we just got the tools working; we didn't even scratch the surface on real Verilog design. My advice for you is to select and buy two or three Verilog (or VHDL) books and read them cover to cover.

Before leaving this project completely, let's see if you can make a few simple modifications to the program. Say Button 2 is on pin 30 and that Button 3 is on pin 69. What would you have to do to the .ucf file to add Button 2 as a "Hold" button and Button 3 as a "Direction" button? What would you have to do to the Verilog file to make the count freeze while Hold is being pressed? What would it take to make the counter count down while Direction is being pressed?