An FPGA (Field Programmable Gate Array) is a type of programmable chip that can be made to behave in just about any way you wish. The FPGA must be configured before it can be used; The configuration process is very similar to programming a computer, except that instead of making a software program behave a certain way on a computer, you're making a chip behave a certain way. Indeed, most people program their FPGAs with a language that looks similar to a typical computer programming language; The two common HDLs (Hardware Description Languages) in the world are Verilog and VHDL (VHSIC (Very High Speed Integrated Circuit) Hardware Description Language). Part of what makes FPGAs interesting is that they are so powerful and versatile that you can make a whole CPU out of them. There is a whole underground community of people creating their own CPU cores out of FPGAs, which can be used as the centerpiece of a normal computer. If this practice becomes mainstream, it could eventually revolutionize part of the way the computer industry works. At this point in time, however, making CPUs out of FPGAs is still mostly the realm of hobbyists and enthusiasts. However, FPGA CPUs are a hot enough topic that there is a news website devoted to them (www.fpgacpu.org) and a HOWTO on CPU design as part of the Linux documentation. (Don't ask me why; I don't see exactly what CPU design has to do with Linux either.)

Part of what seems to be holding up FPGA development is the fact that at this point in time, there is absolutely no standard for how to interface with them. Different companies have their own proprietary standards, and one FPGA seems to be totally incompatible with another, even among products made by the same company. The heaviest hitter in the FPGA arena is, by far, Xilinx, with Altera coming in a relatively distant second. Since each FPGA's design is proprietary, if you want to do something with a Xilinx FPGA (for example), you need to get software from Xilinx that will create a binary configuration file for the FPGA. Nobody else can design such software, because the design is closed. I myself own a Xilinx XC3030, and am totally unable to do anything with it, simply because Xilinx has dropped support for it, so development software is no longer available anywhere. Oh well, maybe the chip would make a nice piece of jewelry or something.

An FPGA is similar to several other types of devices which have been around for quite a while, the difference being that an FPGA is simply much more expandable and versatile. The devices which FPGAs get compared to most often are CPLDs (Complex Programmable Logic Devices), which are similar in function but typically have way less logic gates inside them; Customizable CPU design is much more feasible with an FPGA. Once upon a time, CPLDs also had the distinct advantage of retaining their configuration even when turned off; When FPGAs first came out, they used simple SRAM to hold their configuration, which of course would be lost when the device lost power. Back then, the FPGA had to be programmed from scratch every time it was turned on, usually from a separate serial ROM chip. But today, FPGAs come in Flash, EPROM, and EEPROM variants, which will retain configuration, and which can also be re-programmed. (Fuse and anti-fuse FPGAs also exist, which act like PROMs in that they are one-time programmable, and cannot be reprogrammed afterward.) Despite this, however, most FPGAs still use SRAM for reasons of simplicity (when you need to reprogram it, it's easier to re-encode a small ROM chip than to reprogram a large FPGA chip), so count on having to use a separate boot ROM for the FPGA.

Use of an FPGA is broadly divided into two main stages: The first is "configuration mode", the mode in which the FPGA is when you first power it up. Configuration mode is, as you may have guessed, where you configure the FPGA; That is, this is when you load your code into it, dictating how the pins behave. Once configuration is complete, the FPGA goes into "user mode", its main mode of operation, where the programmed circuit actually starts functioning.

There are a few ways to configure an FPGA:

With a cable attached to a computer Hooking up a cable to a PC's serial or parallel port and having it configure the FPGA through specially-made software is probably one of the simplest solutions. You design your FPGA on the computer screen and generate the code there, then when you're done you just attach the cable and the computer configures the FPGA for you. This way is good for hobbyists who just want to experiment with FPGAs, but for actually producing self-contained FPGA-using units, it is probably a bit impractical, because you need a whole computer attached to the FPGA for this to work. The other obvious drawback is that you need the special cable, and these cables tend to be expensive (often over $100 just for a simple cable!)

With a configuration ROM chip Most FPGA manufacturers also make ROM (PROM, EPROM, or EEPROM) chips which can hold the configuration data and simply be wired to the FPGA to give it its configuration data every time you turn it on. Xilinx, for example, produces its own configuration PROMs, although in most cases, standard third-party ROM chips work just as well and are much cheaper. A dedicated configuration chip is probably the best way if you plan to start producing self-contained units which use FPGAs, since it simply means one more chip on the board gives you all you need to get the FPGA working.

By hand Unfortunately, this option tends to not be feasible for most FPGAs, for two reasons: First of all, many FPGAs use dynamic registers, meaning that they must be configured at a certain speed or the configuration data will get corrupted, and the speeds required are far in excess of what a human could keep up with. Secondly, programming an FPGA is not a dozen-byte affair like the simplest Z80 or 6502 programs; You could program a ROM chip for use with a Z80 by hand in maybe an hour if the program isn't too complex, but even the simplest FPGA configuration usually ends up being thousands of bytes at the least. To program this in by hand (and have to do it EACH time you turn on the FPGA) hardly bears thinking about.

Assuming that you are doing things the "normal" way and connecting your FPGA to a computer, the following is a very high-level list of the basic steps needed to program your FPGA:

1. Write the HDL (Hardware Description Language) code. This is not *strictly* necessary, as the HDL code is to the FPGA as high-level code is to a computer's CPU. HDLs are high-level languages, and they will actually be compiled into binary data before they are loaded into the FPGA. However, creating machine-language code for an FPGA is even more arduous than for a microprocessor, and even professionals are not expected to do bit-level coding for FPGAs. Everybody uses high-level HDLs, which, again, will usually be either Verilog or VHDL. Verilog files end in a .v extension, while VHDL files have a .vhd or .vhdl extension. Write the code to describe the logic circuitry you want your FPGA to emulate, and save it into an HDL source file.

2. Assign pin names. When you program in an HDL, you use names to refer to the pins of the FPGA. These names can be just about anything you want them to be, but the compiler does need to know what name corresponds to what pin. For example, suppose you want pin 10 on the FPGA to be called "input3" in your HDL code. The compiler needs to know that "input3" refers to that pin.

There are two basic ways to assign pin names. You can define them in a separate file. Xilinx uses a UCF (User Constraints File) for this purpose in its software, while Altera's software uses what it calls CSF or QSF files. This file, along with your HDL source file, will be the two files that together provide the information needed to configure the FPGA. The format of this file will be proprietary, and depend upon which manufacturer's product you're using. The other way to assign pins is to simply do it in the manufacturer's proprietary software.

3. Compile the FPGA's binary file. This will be done with the FPGA manufacturer's proprietary software. Xilinx' software for FPGA development is called ISE, while Altera's software is called Quartus. These programs are full-blown development environments, but even if you're not interested in using them, you'll still need to use them to compile the final binary file. This file contains the raw bits that need to be stored inside the FPGA to program the chip.

4. Transfer the bitstream into the FPGA. How you do this will depend on what method you're using to connect to the FPGA, but assuming that you've got it connected to your computer, you'll need some (relatively small and simple) interface utility to upload the binary file to the FPGA.

And... That's it. Once the bits are inside the FPGA, it's been configured.

This is all the important information which can really be given regarding FPGAs without going into specifics of the various proprietary software programs on the market. If you want to put any of this information to use, you need to learn either Verilog or VHDL, find a model of FPGA you wish to use, and then learn to use the particular manufacturer's compiler for that FPGA. Once you've done this, you're ready to start making your FPGA do things.

Xilinx and ISE are registered trademarks of Xilinx. Altera and Quartus are registered trademarks of Altera. This means that you can't start your own company called Xilinx, grow it to huge proportions, and claim you didn't know there was another company called Xilinx. And no, you can't try this with the name Altera either. Oh well.

Back to the main page