Editor's Note: When last we left our intrepid FPGA newbie, Duane, he had just received his FPGA development board (an Avnet Spartan-6 LX9 MicroBoard, which was kindly donated by Xilinx). He opened the package and installed the design software on his computer (See: Discovering FPGAs: What's This All About?)
In this installment, our plucky hero discovers how the signals in the HDL are related to the physical pins on the FPGA, and how these pins are connected to the light-emitting diodes (LEDs) on his development board. Now, back to Duane…
Given my current level of understanding, the thought of trying to design and implement any form of logical function inside an FPGA is rather daunting, to say the least. Considering the complexity of FPGA design relative to the microcontrollers I’m used to, it makes sense to first find a good starting point and establish a frame of reference.
In the case of a new MCU development system, I’ll usually start by flashing an LED on one of the GPIO (general-purpose input/output) ports. The problem with an FPGA is that, until you configure the FPGA, the GPIOs aren’t really connected to anything inside the device, and I don’t know how to find them anyway. While this is a problem, it does lead me to a direction: I first need to figure out the input/output (I/O) connections.
Another good thing to do when working with a new piece of equipment is to minimize any variables. The Xilinx Spartan-6 LX9 Development Board I’m using is accompanied by a complex IDE setup with which I am unfamiliar. In general, I prefer IDEs to command-line processes, but -- as you know -- this is all new to me, so the command-line tool seems a much less complex way to start.
Once I had gotten past these initial decisions, my next step was to take a look at the tutorial, “Blinking LED Design Using Command-Line Tools (Verilog and VHDL)” in the ISE Design Suite 12.4 section on the Support and Downloads page of the Avnet Website (login required).
This tutorial gives a command-line example of a simple routine that makes four LEDs on the board count in binary. It has the sample code both in VHDL and Verilog. (In the future, if something is the same for both VHDL and Verilog, I’ll just refer to the two languages collectively as the HDL, or hardware description language.)
If you’re learning along with me, go ahead and download that tutorial and follow the procedure given in the PDF included in the .ZIP file. I’ll be referring to the schematic as well, which you’ll find farther down on the download page. As you will see, the procedure described in the tutorial is pretty simple, and it quickly takes you through the compile and load steps.
The tutorial's .ZIP file extracts into two directories; one for VHDL and one for Verilog. As shown in the image below, the "source" sub-directories (or "folders," if you prefer that terminology) hold two files: "ledflash.ucf" and "ledflash.vhd" in the VHDL directory, or "ledflash.ucf" and "ledflash.v" in the Verilog directory (this image shows the contents of the "source" directory associated with the VHDL implementation).
The tutorial's .ZIP file extracts into Verilog and VHDL directories.
The "ledflash.ucf" file is identical in both the Verilog and VHDL and directories. The .UCF file extension stands for "user constraint file." This is a Xilinx standard (not to be confused with the .UCF files employed by Epson and WebEx -- the file formats and contents are unique to each situation). These ASCII text files contain user-defined constraints for things that cannot be described in the HDL, such as the logical mapping between signal names in the HDL and physical I/O pins on the device. (UCF files are created using the UCF Generator and opened using the Constraints Editor.)
If we open the “ledflash.ucf” file and look at lines 5 through 8, we see that this is where we map the names of the signals in the HDL to the physical pins on the device that drive the four LEDs on our development board. For example, the contents of Line 5 are as follows:
In this case, "LED" will be a port in the HDL, "0" is the specific bit of the port we wish to access, and “P4” is the name of the pin on the FPGA with which we wish to associate this signal. The remainder of this line is techno-weenie stuff describing the I/O standard being used, the drive strength to be employed, and the slew rate (rate of change) of the signal (the “|” character is a separator that allows multiple lines to be combined into one).
The schematic Sheet 7 shows that pin P4 has been identified by the board designer as net “FPGA_GPIO_LED1,” which connects on the printed circuit board (PCB) to the physical component LED D2. Thus, lines 5 through 8 in the .UCF file map the four elements of the port “LED” in the HDL file to physical pins on the FPGA, which are -- in turn -- connected to four LEDs on the PCB.
Locations of the four LEDs used in this tutorial.
OK, now that we have the pins sorted out, I think I'm finally ready to perform the compile and load steps and make the LEDs on my development board start flashing. The only question that remains at the moment is that I'm not sure if I fully understand the meaning of the terms "compile" and "load" in the context of an FPGA, so please feel free to jump in and add a little insight here if you can.