Close

Understanding Configuration

A project log for FPGA Bootcamp #3

Put your Verilog on real hardware, real cheap

al-williamsAl Williams 07/12/2018 at 20:460 Comments

If you start with a C program, you use a compiler and a linker to convert that code into an executable format. You might use one toolchain to generate a Linux executable and another for a Windows EXE. Still another might produce a hex file to put in an Atmel processor. Even though each takes different tools, the process is more or less the same and it is an analog for how we configure an FPGA.

Whatever tools you use, the workflow for any FPGA is basically the same, although details of the specific tools may vary. Sometimes the names vary a bit, too. Although you write code in Verilog, the FPGA has different blocks (not all vendors call them blocks) that have certain functions and methods they can connect. Not all blocks have to be the same either. For example, some FPGAs have blocks that are essentially look up tables. Suppose you have a look up table with one bit of output and 16 rows. That table could generate any combinatorial logic with 4 inputs and one output. Other blocks on the same FPGA might be set up to be used as memory, DSP calculations, or even clock generation.

Some FPGAs use cells based on multiplexers instead of look up tables, and most combine some combinatorial logic with a configurable flip flop of some kind. The good news is that unless you are trying to squeeze every bit of performance out of an FPGA, you probably don’t care about any of this. You write Verilog and the tools create a bitstream that you download into the FPGA or a configuration device (more on that in a minute).

The general steps to any FPGA development (assuming you’ve already written the Verilog) are:

The place and route step is usually done as one step, because it is like autorouting a PC board. The router may have to move things around to get an efficient routing. Advanced FPGA designers may give hints to the different tools, but for most simple projects, the tools do fine. Synthesize and map are often done in one swoop, also.

One way to think of this is that someone has given you a printed circuit board with a bunch of components holes already drilled out but all the copper is still on it. So you know a resistor is going to go in these holes and an IC in another set of holes. You can't change that. The synthesize and map steps take your design and figure out how to implement it with the components that are there. Like a schematic, though, that doesn't tell you anything about a component's position on the board or any traces. The board might have 10 resistors and you need 3. The schematic doesn't tell you which 3 you are going to use.

The place and route steps then take that schematic and determine which components you will make use of and how to etch the copper to form the traces between them. To carry the analogy further, the configuration step is the etching and building of the board.

Of course, there's no copper and etching involved. That's just an analogy. We'll talk about constraints which can tell the place and route steps that you insist on using a certain component for a certain Verilog construct. That's important when you have, say, a particular I/O pin connected to something and you need a signal to drive it, although there are other reasons you might do it, as well.

Even though we are talking about a very specific board in this bootcamp, you'll find that if you are using Verilog to configure an FPGA the steps will always be pretty close to this. Some tools will have slightly different names or break the tasks up differently, but all of these tasks will still apply.

Another common way to configure an FPGA is with VHDL which is another description language. The workflow is very similar for that, also except you'll use different tools.

There are other tools people use to configure FPGAs. Sometimes they will allow you to create configurations using a subset of a common language like C. Or you'll find graphical tools that let you pick predefined function blocks and compose them to make -- essentially -- a custom CPU. While these steps won't be happening visibly, they still occur somewhere under the covers.

Discussions