Operating System

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

While it is possible to do professional FPGA development 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 less intrusive, 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’ll use to set up my FPGA development environment.

There are no commercial FPGA tools officially supported on macOS. It is possible to use a minmalist 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.

Baremetal vs. Virtual Machine

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 Sequioa (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 sometimes macOS) devices directly and leave the management of the tools-specific Linux virtual machines mostly 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 at work use it for their daily work already), though there are still some quirks to deal with. A minor one is the rendering of GUI 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 personal 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 a) it’s the one we use at work, b) it provides the best user experience I’ve had when writing VHDL, and c) it offers a fully-featured free license for personal use.

The major drawback of Sigasi 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 alternative to Sigasi Visual HDL. 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’ll still keep it mainly as a backup for when I can’t use Sigasi 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 will include in my FGA development environment: Questa and GHDL.

Questa

Questa is an HDL simulator developed by Siemens. Questa is very popular in FPGA development, in fact it is offered as the official simulator for Altera and Lattice devices - AMD includes its own simulator with Vivado.

The bundled versions of Questa include all the functionality that we need for professional FPGA development, but are limited in several key ways. These include 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’ll use the intelFPGA version Questa as the main simulator for my personal projects because it is available free of charge and it is supported by VUnit. Questa is also the simulator that we use at work.

GHDL

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 relatively modern look-and-feel (especially when compared to the ancient UI/UX of the commercial waveform viewers - even the really expensive ones), and it 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’ll 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 years now, however it has a rather outdated look and feel.

Testing Framework

Logic simulations are a critical step in the design of degital systems for FPGAs (and ASICs). 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.

For my FPGA development environment Ill use VUnit as my verification framework. VUnit 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 my day job.

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.

Build System

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

Different tools offer different command-line interfaces and scripting mechanisms, often using different languages (Tcl is very popular in the semiconductor EDA world). 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- (and Asic-) 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’ll install Make as the default build system for my development environment, but will make sure to dive into the FPGA-specific ones eventually.

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’ll use Cheby because it is available free of charge, supports VHDL, and is written in Python.

Summary

These are the 9 elements that I’ll use to setup my FPGA development environment:

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

  2. Bare metal vs. Virtual Machine: I’ll install Ubuntu in a virtual machine running on VMWare Fusion in macOS.

  3. Code Editor: I’ll use VSCode with the Sigasi Visual HDL extension. TerosHDL will be my backup extension for offline work and ARM support.

  4. Simulator I’ll use Questa as my main simulator, with GHDL as a backup for ARM support.

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

  6. Verification Framework: I’ll use VUnit for managing simulation runs.

  7. FPGA Toolsuite: I’ll use AMD’s Vivado toolsuite targeting 7 Series and UltraScale+ devices.

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

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

Cheers,

Isaac