One of the most valuable lessons I’ve learned after more than a decade of working with digital design for FPGAS, is that having a development environment with all the tools that we’ll need at each stage of the design process can help us work more efficiently, effectively and comfortably. This results in us not only being able to do better work, but also enjoying the development process itself.

In this article I describe the 10 elements needed for setting up a professional FPGA development environment, including specific choices for each category. By the end of this article you will have a complete selection of tools to start (or finish) setting up your own environment for designing digital systems with FPGAs.

Operating System

Windows and Linux are the standard operating systems for FPGA development.

While it is possible to do professional FPGA work on Windows, there are several advantages to using Linux. Often the Linux versions of the FPGA tools get new features before they are rolled out on Windows. Also, most open-source frameworks are developed for Unix-like systems, and running them under Windows is often awkward, sometimes simply not possible. On a more subjective note, Linux offers a leaner user experience compared to Windows, which many developers prefer.

Ubuntu is one of the most popular Linux distributions available. It has stable releases with long-term support, and its large user base makes it easier to find support online. This is the distribution that I use in my FPGA development environment.

There are no commercial FPGA tools officially supported on macOS. It is possible to use a minimalist setup for logic simulation with open-source tools, but when it comes to generating a bitstream to be programmed on an actual FPGA device, Windows or Linux will always be needed. Moreover, commercial FPGA tools only support x86 architectures, so running them in virtual machines on Apple Silicon computers (which are ARM-based) would require emulation. While this is theoretically possible, it might be tricky to setup and maintain, potentially causing more trouble than it is worth.

Hypervisor

Once we have settled on an OS, we must decide how to run it.

Even though Linux support for laptops has improved in recent years, I still find it can be hit-or-miss in several minor aspects that add up to a suboptimal user experience. That’s why I prefer to run my Linux FPGA development environment in a virtual machine.

For my own projects I use a 2018 Intel MacBook Pro running macOS Sequoia (probably the last version of macOS to be supported on this hardware), while at work we use Windows workstations as hosts for Linux virtual machines. The latter setup is often preferred by IT departments in medium and large companies, who’d rather deal only with Windows and macOS devices directly and leave the management of the tools-specific Linux virtual machines to the development teams.

For both my own projects and at work I use the virtualization software from VMWare - Workstation for Windows and Fusion for macOS. Both tools offer a fully-featured version free of charge for personal use. Alternatively there is VirtualBox, a free and open-source virtualization solution with a feature set similar to the VMWare products.

When running Windows, another option is to use the Windows Subsystem for Linux, WSL. The second version, WSL2, supports GUI-based tools, a must for FPGA development. In my experience WSL2 is suitable for professional development - several colleagues use it for their daily work already - though there are still some quirks to deal with. A minor one is the rendering of graphical apps, which might not always behave quite as one would expect. A somewhat bigger issue is the support for passing through USB devices, which is more cumbersome than what the VMWare and VirtualBox products offer.

Code Editor

There are many code editors from which to choose, all catering to different preferences and idiosincracies. Both at work and for my own projects I use VSCode.

VSCode is built by Microsoft on a semi-open source basis. In recent years it has gained popularity across many software development communities. This popularity has enabled a rich ecosystem of extensions, which in turn makes it more appealing to use VSCode, reinforcing a virtuous cycle.

HDL Extension

A dedicated HDL extension will dramatically improve our development experience. I use Sigasi’s Visual HDL because it’s the one we use at work, it provides the best user experience I’ve had when writing VHDL, and it offers a fully-featured free license for personal use.

The major drawback of Visual HDL is that its free version requires talkback to be enabled. The developers ensure that the talkback is limited to usage information and does not include any code. Still, an internet connection is required for the extension to work, which might be inconvenient at times.

TerosHDL is a free and open-source HDL extension. It can absolutely be used as the only HDL extension for professional development, in fact, I find TerosHDL better in some aspects, like the way it manages libraries and the fact that it can be installed on ARM-based PCs. Having said that, I still use it mainly as a backup for when I can’t use Visual HDL.

Simulator

A critical step in FPGA development is logic simulation, where we verify the correctness of our hardware description using a simulation tool. There are two that I use regularly: Questa and GHDL.

Questa is an HDL simulator developed by Siemens. It is very popular in FPGA development, in fact, it is offered as the official simulator for Altera and Lattice devices.

The bundled versions of Questa include all the functionality that we need for professional FPGA development, but are limited in several key ways, like slower simulation speeds, lack of support for advanced SystemVerilog features for verification, and support only for the simulation libraries of the FPGA manufacturer with which it has been bundled. Despite these limitations I use the intelFPGA version of Questa as the main simulator for my own projects because it is available free of charge and it is supported by V-Unit. Questa is also the simulator that we use at work.

For VHDL-only designs, we can use GHDL, a free and open-source simulator. GHDL is a much smaller and more lightweight application when compared to Questa, and because it’s free, there is no licensing or feature limitations. GHDL also runs on ARM-based PCs.

Waveform Viewer

When doing FPGA development, we spend a lot of time looking at waveforms. While most commercial simulators include a waveform viewer, most free and open-source simulators (like GHDL, but also Icarus Verilog and Verilator) do not. In these cases we need a standalone waveform viewer which can display the data generated by the simulators.

Surfer is a relatively new free and open-source waveform viewer. It has a modern look-and-feel (especially when compared to the ancient UI/UX of the commercial waveform viewers - even the really expensive ones). Surfer can run as a standalone app, in a web browser, or as a VSCode extension. This last option makes it especially useful for inspecting waveforms without leaving our code editor, which is why I include it in my development environment.

GTKWave is a free and open-source waveform viewer. It has been the most popular alternative to commercial waveform viewers for many years, however it has a rather outdated look and feel.

Testing Framework

For all but the most trivial designs, using a verification framework to help us manage testcases and simulation runs will make the verification process much more enjoyable.

I use V-Unit as my verification framework. V-Unit is probably the most popular framework for verification in VHDL, though it also supports SystemVerilog. It is also widely used in Europe, where VHDL is the preferred language for FPGA development. We also use it at work.

Another open-source verification framework worth checking out is SVUnit, which focuses more on SystemVerilog and the Universal Verification Methodology, UVM. Also, the two most popular VHDL verification libraries, OSVVM and UVVM, have built-in mechanisms for managing the verification process.

FPGA Toolsuite

The ultimate goal of FPGA development is to generate a bitstream that we can program into our device. To do this we need to install the tools provided by the FPGA manufacturer. Though there are open-source tools for generating bitstreams, most professional development teams use the official toolsuite for their target device.

Because most of the projects at work (including the one I’m currently working on) use AMD devices, I’ll stick to Vivado and Vitis. I’ll dive into other manufacturers’ tools in the future.

Register Generator

Using a processor tightly coupled with the FPGA logic has become increasingly common in recent years. One challenge that this presents is how to efficiently and consistently manage the register interface between the software and the programmable logic.

There are several free and open-source frameworks for generating and managing registers, like hdl-registers, airHDL, RgGen, PeakRDL/SystemRDL and Cheby. I use Cheby because it is available free of charge, supports VHDL, and is written in Python.

Build System

Though we’ll need to interact with the tools via their graphical user interfaces at some point, we’ll also want to automate most interactions using scripts. Scripts have two key advantages: accelerate task execution without human intervention, and they are self-documenting and guarantee replicability across different environments.

Different tools offer different command-line interfaces and scripting mechanisms, often using different languages. One way to streamline the tool interactions is to use a build management system as an abstraction layer between our project and the tools that ultimately performs the tasks in the development process (simulation, implementation, bitstream generation, etc.). It is also useful to have a way to perform actions that involve different tools from a centralized interface.

There are several FPGA-specific build systems, like EDAlize, PyFPGA, HDL on Git (HOG), Hdlmake, Firmware Framework and tsfpga. Some of those are built on top of more mainstream build management systems, like Make or Ninja. I use Make as the default build system for my development environment, but I’ll make sure to dive into the FPGA-specific ones eventually.

Summary

These are the 10 elements that I use in my FPGA development environment:

  1. OS: Most commercial FPGA tools are supported on Windows and Linux. I use Ubuntu.

  2. Bare metal vs. Virtual Machine: I run Ubuntu in a virtual machine inside VMWare Fusion in macOS.

  3. Code Editor: I use VSCode for code editing.

  4. HDL Extension: I use Sigasi Visual HDL for most of my work, with TerosHDL is a backup.

  5. Simulator I use Questa as my main simulator, with GHDL as a backup.

  6. Waveform Viewer: in addition to the one included in Questa, I also use Surfer as a VSCode extension for a more modern look and feel right inside the code editor.

  7. Verification Framework: I use VUnit for managing simulation runs.

  8. FPGA Toolsuite: I use Vivado and Vitis to target 7 Series and UltraScale+ devices.

  9. Register Generator I use Cheby for automated register generation.

  10. Build System: I use Make as a build management tool, though I’ll explore some of the FPGA-specific alternatives in the future.

Cheers,

Isaac