This site uses cookies to deliver our services and to show you relevant ads and job listings. By using our site, you acknowledge that you have read and understand our Cookie Policy , Privacy Policy , and our Terms of Service . Your use of the Related Sites, including DSPRelated.com, FPGARelated.com, EmbeddedRelated.com and Electronics-Related.com, is subject to these policies and terms.

Building a bitstream from an HDL is a complicated process that requires the cooperation of a lot of tools. You can hide behind an IDE or grow a pair and use command line tools and a makefile to tie your build process together. I am not a huge fan of makefiles either (I believe a language should be expressive enough to automate the build process), but the alternatives are dismal.

Command-line driven workflow is easier on the hands and faster. The example project (just an LED blinker) goes from zero to bitstream in less then 20 seconds on my machine. And I am allowed to use Emacs for editing code.



Xilinx tools do not make it easy to be organized: they are picky about where certain files are. They spew out fountains of logs, reports and temporary files from each component. Each component requires a lot of settings, and often script files where even more settings are stored. With a little planning and investigation, there are ways to keep this mess under control.

I often create projects that work on several different devboards, sometimes with different FPGAs, and generally with different pinouts. With a makefile, it's pretty easy to maintain a single codebase and build for a different board when needed.

While I am not entirely happy with my setup, it's pretty minimal, requires few changes when new files are added, and supports multiple configurations. I've seen possibly better make environments, but they are much more complicated, and I like keeping it simple. Since it took me a stupid long time to get to this point, I would like to share a minimal Xilinx build environment with you. You can use it as a starting point in your projects, although I can't vouch for the correctness of any settings!

So to start with, I organize my projects as follows:

This way I can keep the source files (and the dreaded .prj file; more on that later) in the src directory. Xilinx tools can pollute the ise directory where our Makefile sits (and 'make clean' wipes it clean, of course). Note that the xst directory (and projnav.xst/ inside it) is required by the 'xst' executable to keep temporary files. The board directory contains board and chip-related files and allows me to build the project for different devboards.

My basic Makefile is very simple (git clone an improved one from https://github.com/stacksmith/xilinx-makefile.git- this is just a picture):

A few observations:

The clean section is massive. I add to it often, and Xilinx tools manage to outsmart me by generating new kinds of crud all the time.

I generally use -intstyle silent to keep screen output to a minimum.

xst uses top.xst script. It in turn refers to the project file, src/top.prj. This file contains a list of source HDL files. This is riduculous - this information belongs in the makefile! I haven't had any luck with cleaning this up, so when new HDL source files are added to the project, I add a line to the .prj file and modify the makefile.

This leaves a bad taste in my mouth, but is not that hard. If you figure out how to let xst know about the source files without the darned .prj files, please let me know!

UPDATE: nrclark (who knows a few things about makefiles) resolved the issue by having the makefile parse the prj file and create SOURCES automatically! Thanks!



References:

git clone https://github.com/stacksmith/xilinx-makefile.git



UG628 Xilinx Command Line User Guide (formerly devref)

UG627 Xilinx XST User Guide



