An FPGA Manifesto

The road is hard and there is a lot to learn. This is actually good. If you are looking for something interesting to learn about along with a challenge, this is a great path. I came to FPGA from a background in embedded software. Working with FPGA got me out of my "comfort zone" and into an entirely new domain.

A quick note up front. So far I have worked entirely with Xilinx FPGA devices. Xilinx is the major FPGA manufacturer, with Altera coming in as a second. Other makers are bit players. Lattice is notable because their devices have open source development software, but they make up only a tiny part of the FPGA market. My experience though is entirely with Xilinx devices and I can only tell you what I know about.

You don't end of configuring a bunch of gates. This is sort of how I imagined working with FPGA would be. As it turns out, the manufacturers don't even document how the FPGA are laid out at the hardware level. On top of that, FPGA are set up with larger fundamental blocks than gates. You deal with CLB's (among other things) which are configurable logic blocks. You configure the CLB itself, then connect it to other CLB. And you don't even do that, you work at a much higher level, but that is what ends up happening.

• A discussion of FPGA "entities"

What you do work with is an HDL language (either Verilog or VHDL). You can work up a digital design without any knowledge of what sort of device it will end up running on. When you do want to put it on a real device, that is done by "synthesis" software, which is pretty much a black box. This can be frustrating for someone like me who is curious about what is going on at a deeper level, but it is also liberating.

You never design using graphical tools with schematics full of logic gates. All of that pretty much went out the window at least 20 years ago, and it is a good thing. You can get a lot more done working at a higher level, and your designs will be portable. For some people, an FPGA is a middle step along the path towards designing integrated circuits. A design is worked up in Verilog. Then the design is exhaustively tested using simulation software. Then the design could be synthesized for a target FPGA and subjected to additional testing. Finally the design could be synthesized for actual "hard" implementation in silicon.

An FPGA is not necessarily faster than a microprocessor. You can indeed design a processor in verilog and then run it on an FPGA. Odds are that the same processor running in hard silicon would be faster. What an FPGA can do is to run certain things faster than sequential code running in a microprocessor could do. No doubt you could generate custom silicon that could run it faster yet, but what the FPGA offers is versatility. An FPGA can do literally anything that could be done in the digital domain, limited only by the on chip resources.

A specific example - the Xilinx ZYNQ

The resources in the ZYNQ fpga are like so:

XC7Z010  - Zynq-7000  2011  2200 clb, 17600 6-lut, 1500 slicem,  60 bram,  80 dsp, 2 cmt, 100 uio
XC7Z020  - Zynq-7000  2011  6650 clb, 53200 6-lut, 4350 slicem, 140 bram, 220 dsp, 4 cmt, 200 uio

The Zynq has two "sides". One side consists of a dual core ARM processor and a bunch of the usual peripherals (uart, network, timers, interrupt controller). The other side is the FPGA. The lingo is that the PS is the arm side (the "processing system"). The PL is the fpga side (the "programmable logic"). They talk to each other via an AXI bus, but that is another topic entirely.

The ARM cores run at 667 Mhz, much faster than a processor core running in the FPGA could run. I spent my first several months just working with the ARM side of the chip, ignoring the FPGA, and writing a variety of bare metal code projects.

You can turn the table and ignore the ARM side (as well as the AXI bus) and just work with the FPGA. You can work up designs in Verilog using Vivado , download them via JTAG into the FPGA and run them.

Xilinx software

You can ignore ISE unless you are working with a really old Xilinx device like the Spartan 3E (which I have and forces me to use ISE).

Vivado is the tool you use to start with Verilog (or VHDL) and end up with a bitstream that can be downloaded into your FPGA. It replaces ISE for all the newer devices, and is still the state of the art tool for doing things with Verilog.

The SDK is what you use if you have a Zynq device and want to write C code that will run in the ARM side of the Zynq. If you have an FPGA only device like a Spartan-6 you can ignore it. Besides that, in 2019 Xilinx abandoned the SDK and moved on to Vitis, but the 2019 SDK is still available, along with the 2019 Vivado that works in conunction with it.

Vitis replaces the SDK, but does not replace Vivado. If you want to work in Verilog, you still use Vivado. Along with replacing the SDK, Vitis provides several ways to write C code and get it into the FPGA (if you can believe it). Xilinx is trying to find ways to allow C programmers to utilize FPGA resources without having the learn Verilog. They call this "HLS" (high level synthesis). I have had no dealings with this whatsoever. They also have something else (SDSoC) which allows C code to be synthesized as part of a Vivado block. This sounds like more HLS to me, but there is apparently some distinction I am missing. At any rate, the game with Vitis is that you work in C in all cases. I will probably learn how to use Vitis to replace the SDK (for no particular reason).

Vivado "calls home" in some way to verify that you are allowed to do what you are trying to do. This may upset some people, but it is fine by me, and the only game in town. It apparently gets permission for the specific part you are working with. This is nice, because Xilinx from time to time puts more parts on the list of parts that the Webpack version is allowed to work with, and you don't have to do a thing to start using one.