FPGA openSource tools

In this post we look at some of the most popular open-source tools for FPGA design and verification.

 

Traditionally, when we create an FPGA design we have to use proprietary software tools to simulate and build our design.

 

For example, when we create a design that targets a Xilinix FPGA we would typically use Vivado software.

 

This means that when we target a different FPGA vendor we, also have to learn how to use a different tool.

 

While this may not sound like much of a problem, it often takes time to get comfortable with the features of the software as well as the scripting languages associated with them.

 

However, several open-source tools have been developed in the last few years which are aimed at simulating and building FPGA designs.

 

Although these tools still have a long way to go before they support every FPGA on the market, they already offer support for a number of FPGAs from Lattice and Xilinx.

 

As a result of this, we can often use the same open-source toolchain for many different FPGA projects.

 

In addition to this, a lot of effort is being made to support more devices and introduce extra features.

 

All of this means that open source FPGA tools are quickly advancing to the point where they can compete with commercially developed software.

 

In the rest of this post, we look at some of the most commonly used open-source software tools which we can use when designing FPGAs.

Simulation Tools

There are several open-source FPGA tools which have been designed as an alternative to expensive software such as QuestaSim and Synopsys VCS.

 

One of the main advantages of using open source simulators is undoubtedly the price.

 

Whilst most vendors offer some form of free simulation tool, we tend to get useful extra features when we use open source simulators instead.

 

For example, we often find better support for simulation libraries such as UVM with open source tools.

 

In addition to this, open-source simulators are often simpler to use than their commercial alternatives.

 

Despite these advantages, we must also consider some of the downsides to open source simulators.

 

Perhaps the biggest drawback to using open source tools is that they tend to be slower than commercial tools.

 

The exception to this rule is Verilator, which offers performance that is comparable to many commercial simulators.

 

However, we still get better performance from a top of the range commercial simulator than we do from Verilator.

 

Another problem we have when we use open-source simulators is that they don't support encrypted IP blocks.

 

This is a problem if we want to use IP from vendors such as Xilinx as all of the simulation models which they supply are encrypted.

 

Finally, there are currently no open-source simulators that offer multi-language support.

 

As a result, we will not be able to use an open-source simulator when we create a design that uses both VHDL and verilog.

 

While this is not generally a problem, we may have instances where we wish to design our FPGA using VHDL and create a testbench using SystemVerilog.

 

We can't use this approach with the currently available open-source simulators.

 

Let's take a look at some of the most popular open-source simulators.

Icarus Verilog

The Icarus Verilog software tool is an open-source verilog compiler that includes a synthesizer and simulator.

 

We can use Icarus Verilog on Linux, macOS and Windows operating systems.

 

Icarus Verilog supports all features of the verilog 2005 standard, as well as a limited amount of SystemVerilog.

 

By default, we can't view waveforms from our simulation when we use Icarus Verilog.

 

However, we can export our simulation results into the open-source GTKWave program when we need to view the waveforms.

 

Icarus Verilog is one of the most popular open-source verilog simulators. In fact, it is so popular that it is even one of the featured simulators on EDA playground.

 

One of the reasons for this is that it offers extremely good support for all features of the verilog 2005 standard.

 

In addition to this, a community of developers actively maintain Icarus Verilog and regularly update it with new features.

Simulating Designs with Icarus Verilog

When we use Icarus Verilog to simulate our designs, we have to take two steps.

 

Firstly, we have to compile our design into an object which the internal simulator can use.

 

We can do this using the iverilog command line program. The code snippet below shows the general syntax we use to do this.

 

iverilog -o <output_name> <input_name>

 

In the above example, we use the <output_name> field to give a name to the compiled output.

 

We use the <input_name> field in the above example to specify the verilog file that we want to compile.

 

After we have compiled our verilog code we then need to call the simulator using the vvp command line program. The code snippet below shows the general syntax we use to do this.

 

vvp <filename>

Verilator

The Verilator tool is an open-source verilog compiler that only accepts synthesizable verilog or SystemVerilog code.

 

Unlike Icarus Verilog, we use Verilator to compile our verilog code into another programming language - either C++ or SystemC.

 

As a result of this, we can't directly simulate the compiled objects which Verilator creates.

 

Instead, we have to write some SystemC or C++ code which we can then use to simulate our design.

 

We can then use a standard C compiler, such as GCC, to compile our SystemC/C++ design into an executable file that we can run.

 

As we can see from this, when we are looking for a basic verilog simulator it is generally simpler to use Icarus Verilog.

 

However, Verilator offers a number of advantages in comparison to other open-source and commercial compilers.

 

Perhaps the biggest advantage of using Verilator to simulate our designs is speed.

 

In comparison to Icarus Verilog or GHDL, our simulations will run much quicker when we use Verilator.

 

In fact, Verilator also performs better than most free tools which are provided commercially by companies such as Xilinx and Intel.

 

However, we will generally find that expensive paid simulators, such as QuestaSim, offer better performance than Verilator.

 

Another advantage of Verilator is that it enforces strict linting rules. When we write code that can't be synthesized, Verilator will raise errors and tell us what is wrong with our code.

 

As a result, we will be able to find bugs in our design much earlier in the design process.

GHDL

The GHDL software is an open-source VHDL compiler and simulator which has been around for nearly 20 years.

 

In addition to this, it also features some VHDL synthesis capabilities, although this is currently not fully implemented.

 

In many senses, we can consider GHDL to be the VHDL equivalent of the Icarus Verilog tool.

 

We can use GHDL on virtually any operating system, including Linux, Windows and macOS.

 

GHDL currently offers full support for the VHDL-87, 93 and 2002 standards. In addition, there is also partial support for the VHDL-2008 standard.

 

As with Icarus Verilog, we can't view waveforms from our simulation when we use GHDL.

 

However, we can export our simulation result to the open-source GTKWave program when we want to view the waveforms.

 

GHDL is the most popular open source VHDL simulation tool. In fact, it is so popular than it is even one of the featured simulators on EDA playground.

 

One of the main reasons for its popularity is the fact that it offers reliable support for many useful features of VHDL-2008.

 

This is directly comparable to many commercially available simulators, most of which still don't fully support VHDL-2008.

 

In addition to this, there is a community of developers which maintains the code on github. As a result, we regularly get new features and bug fixes for the software.

 

Finally, we can also use popular simulation libraries such as UVVM or OSVVM in GHDL.

Simulating Designs with GHDL

When we want to simulate a design using GHDL, we have to take three separate steps.

 

Firstly, we have to run an analysis stage. We use this step to convert our VHDL source code into a format that is used internally by GHDL.

 

The code snippet below shows the command we use to run the analysis step.

 

ghdl -a <input_name>

 

In this example, we use the <input_name> field to specify which VHDL file we want to run the analysis on.

 

Once we have run the analysis step, we can then compile our design into machine code using the elaboration step.

 

The code snippet below shows the command we use to run the elaboration step.

 

ghdl -e <input_name>

 

In this example, we use the <input_name> field to specify which design we want to elaborate.

 

Once we have compiled our VHDL source code into machine code, we can then run our simulation.

 

The code snippet below shows the general syntax we use to run the simulation.

 

ghdl -r <test_name>

 

In this example, we use the <test_name> field to specify which simulation we want to run.

 

We can also skip the elaborate step as it is also run as a part of the run command.

 

However, we get extra warnings about our design when we run the elaborate step separately. This can be useful for finding bugs in our design.

Tools for Building FPGA Designs

There are now a number of open source tools that we can use to convert our source code into a bitstream.

 

This includes tools that allow us to synthesize our verilog or VHDL code, perform place and route operations and create a bitstream to program into our target FPGA.

 

However, most of these tools are fairly new developments that have appeared in the last ten years.

 

Despite this, we have already started to see open-source tools find use with industrial customers. In particular, the toolchain for building several Lattice FPGAs is now entirely open source.

 

In addition to this, large, coordinated projects such as symbiflow are helping to accelerate the development of these tools.

 

Let's look at some of the most popular open-source tools which we can use to build FPGA bitstreams.

Yosys Synthesis Tool

Yosys is an open-source verilog synthesis tool that supports almost all features of the verilog 2005 standard.

 

Thanks to the fact that it is highly customizable and extensible, Yosys is the most popular open-source FPGA synthesis tool.

 

Yosys is actually a collection of related software tools which can be used to build a complete synthesis tool.

 

As a result of this, we can easily customize the synthesis process depending on our needs.

 

For example, we may want to use a different process for high-speed designs and low-speed designs.

 

We use tcl based scripts to customize the synthesis flow for different FPGAs. This approach means that it is actually relatively simple to customize Yosys for different requirements.

 

However, we can also simply use generic synthesis flows when we require a basic synthesis flow.

 

In addition to this, we can also customize the Yosys source code if we wish to add extra features to the tool.

 

After synthesizing our design using Yosys, we can also export the netlist to several different file formats, such as blif, JSON or edif.

 

This is beneficial as it means that we can export our netlist to different place and route tools, depending on our exact toolchain.

 

In addition, we can also generate our netlist in verilog. This allows us to carry out post-synthesis simulations on our design.

 

At the moment, we can only use Yosys to synthesize FPGAs from the Lattice iCE40 or Xilinix 7 series families. However, the developers are making efforts to support more FPGA families.

 

One disadvantage of the Yosys synthesis software is that it doesn't currently support VHDL based designs.

 

However, we can use the open-source GHDL tool as a front end for Yosys when working with VHDL. This approach means that we generate a simple netlist using GHDL and then use Yosys to optimize it.

 

The only downside to this approach is that the synthesis support in GHDL is still experimental.

VPR Place and Route Tool

The Versatile Place and Route (VPR) tool is an open-source place and route tool which was first developed at the University of Toronto over 20 years ago.

 

We can use the VPR tool to perform placement, routing and analysis operations on our netlist.

We can use synthesis tools such as Yosys to generate our netlist and then export it into a VPR project.

 

Alternatively, we can also use the Verilog-to-Routing package which includes both VPR and a separate synthesis tool.

 

We can use VPR on Linux and macOS based operating systems. In addition, we can also use cygwin in order to run VPR on windows.

 

VPR was originally developed to provide a reliable software tool that can be used for testing out new routing algorithms. As a result of this, we mainly see VPR being used in academic and research projects.

 

This means that it can be difficult to use when we want a simple way of building our code for readily available FPGAs.

 

This feature means it is not really suitable for use in a simple VHDL/verilog-to-bitstream toolchain.

Arachne Place and Route Tool

The Arachne PNR tool is an open-source place and route tool which was first released in 2015.

 

We can use Arachne to perform place and route operations for the Lattice ice40 family of FPGAs. Currently, this software does not support any other FPGA families.

 

Arachne was the first open-source place and route tool which was used in a verilog to bitstream toolchain with industrial users.

 

Whilst this represented a major milestone for open-source FPGA tools, there are several limitations to this software.

 

As we have already mentioned, we can only use Arachne with the Lattice ice40 family of FPGAs.

 

This means that we can only use Arachne with a very small subset of FPGA devices.

 

In addition to this, Arachne uses a routing algorithm with is not timing driven. This means that the tool doesn't prioritize achieving the fastest maximum clock frequency when it performs the place and route operations.

 

As a result of this, we can typically achieve better timing results with the same source code when we use a different place and route tool.

 

Although we can still use Arachne, the code base is no longer actively maintained. As a result, we should use the nextpnr tool rather than Arachne for new projects.

Nextpnr Place and Route Tool

The nextpnr tool is an open-source place and route tool which was first released in 2018. It was originally developed as a replacement for the Arachne place and route tool.

 

Since its release, it has grown to become the most popular open-source place and route tool.

We can use nextpnr on Windows, macOS and Linux based systems.

 

In addition to this, we also get a GUI interface as a part of the software. This is in contrast to all the other tools we have looked at so far which only have a command line interface.

 

This can be a useful feature as it allows us to more easily debug our design by visualizing the circuit in the FPGA.

 

Currently, nextpnr is primarily aimed at Lattice FPGAs with full support being offered for the ice40, ECP5 and Nexus families.

 

However, work is currently being carried out to support more FPGAs in the future, in particular the Xilinx 7 Series family of FPGAs.

 

Unlike Arachne, nextpnr uses a timing driven routing algorithm. This means that nextpnr priorities achieving the highest possible clock frequency for a given design.

 

As a result of this, we can achieve higher frequency designs when we use nextpnr.

 

However, the downside to this is that it typically takes longer to place and route a design.

 

As we discussed with Yosys, we can also easily extend the functionality of the nextpnr tool as it is open source.

 

In fact, this is even easier to do with nextpnr as it features a python interface as well.

 

Nextpnr is currently the most popular open-source place and route tool by some margin. As a result of this, it is also used in popular verilog to bitstream projects such as symbiflow and apio.

Bit Stream Generation

The final stage in creating an FPGA programming file is generating the actual bitstream itself.

 

As most FPGA vendors keep the contents of their bitstreams a secret, there are fewer open-source tools available for the generation of bitstreams.

 

However, there are currently several projects which are aiming to document the format of these bitstreams.

 

At the moment, there is full documentation available for the Lattice ice40 (project icestorm) and ECP5 (project trellis) families of FPGA.

 

We can also use tools included in these projects to generate bitstreams which we can program into our target FPGA.

 

There is also some documentation for the Xilinix 7 series family (project x-ray) although this is not currently complete.

 

Also Published here