Can We Do Better Than Verilog and VHDL for FPGAs?

At some point during a FPGA engineers’ career, they will be faced with a difficult bug in their VHDL or Verilog code and they’ll ask themselves: “Why are we stuck with such difficult languages?” When we look to almost any other sort of chip, including CPUs and GPUs, a new, easy and well supported language emerges every other year. We have been stuck with Hardware Description Languages (HDLs) like Verilog and VHDL since the 80s. Why has no-one found a better method?

The history of VHDL

The answer to this is that the entire FPGA community is trying hard, but the nature of FPGAs makes this task difficult to pull off. To understand why this is, we need to look at the original purpose of FPGAs. The FPGA manufacturer Xilinx was founded in 1984, a full year after the release of VHDL. Originally, VHDL was designed by the US military as way of precisely documenting the behavior of Application Specific Integrated Circuits (ASICs).

Xilinx marketed FPGAs as way of emulating the behavior of ASICS without the need to manufacture them first. VHDL was then naturally supported by Xilinx’s tools because that is what ASIC engineers were using.

Verilog would also be invented in 1985 but kept as a proprietary language by Cadence Design Systems until 1990. It differed from VHDL because it was more similar to C++, but still simulated circuits. To this day, products like the Arty Z7 can still be programmed in these languages (https://digilent.com/shop/arty-a7-100t-artix-7-fpga-development-board/). They are now even supported by modern DevOps tools such as BeetleboxCI (http://beetlebox.org).

The difficulty to using HDL is because it is trying to map the behavior of a circuit at the Register Transfer Level (RTL). This is when data in the form of electronic signals moves from one register through a series of logical gate and to the next register within a certain period known as a clock cycle. A single ASIC will have billions of these signals moving at any given clock cycle and the designer uses VHDL to specify how this should occur. This naturally makes it language that only specialists can use and they then need a long time to properly simulate and debug FPGA designs.

Why are languages for other chips so much easier?

At a basic level, most other chips including CPUs, are designed to run a list of instructions sequentially. Typically, this will be tasks like moving data or perform arithmetic and this list of instructions would be written in the low-level assembly language.

This low-level language is difficult for humans to understand, so higher-level languages were invented that were more human readable like C. Even these languages though required programmers to understand concepts like memory management, so even higher-level languages were developed to make coding simpler.

High Level Synthesis (HLS) tools

If we could take these high-level languages, such as C, and use them for FPGA designs then we could gain the performance benefits of custom hardware without needing to write HDL. This is exactly what High Level Synthesis (HLS) tools have been attempting to do since the 90s. HLS tools have significantly improved since then and are supported by industry. Industrial tools include AMD’s (formerly Xilinx) Vivado HLS, Intel HLS Compiler and MicroChip’s SmartHLS.

These HLS compilers are often not perfect because these languages were designed to become list of instructions, not circuits. Only a limited amount of C can effectively be transformed into a circuit and still have the superior performance FPGAs are known for. Long sequences of ‘if’ statements perform poorly, whilst ‘for’ loops can be transformed well.

Because of this, new generation of tools have been created that use a combination of both CPUs and FPGAs. This combination can place the two on a single chip known as a System-on-Chip with a shared memory space. They can also be separate chips that are linked via a PCI interface. Tools that use this technique include Intel’s OneAPI and AMD’s Vitis Unified Development environment.

Domain Specific Tools

Another promising area are domain specific tools that build designs for specific applications. The most popular type of these tools is for the machine learning domain, which FPGA technology has shown a lot of promise in. TYpically these tools will take a model from a popular machine learning framework such as PyTorch or TensorFlow and then build an optimized design for that model.

This means that software developers can use FPGAS with no expertise, whilst also maintaining impressive performance. Community tools for this include FINN (https://github.com/Xilinx/finn) and HLS4ML (https://github.com/fastmachinelearning/hls4ml). Industrial tools include Vitis AI (https://www.xilinx.com/products/design-tools/vitis/vitis-ai.html), Intel OpenVINO (https://docs.openvino.ai/latest/home.html).

Other HDLs

Finally, there have been attempts to make HDL more accessible by using languages software engineers are more familiar with. These differ from HLS tools because they enable developers to describe the hardware at the RTL level and not just improve performance of software concepts like ‘for’ loops. These attempts are mostly open source and run by the community. These include:

The major problem with these languages is that the FPGA community is quite small, which makes supporting Open-Source projects more difficult than in software communities. There has also been little interest in industry tools supporting these HDLs and so most of these languages translate to an intermediate representation, such as an HLS tool, VHDL or Verilog.

Conclusion

Throughout most of the FPGA industry’s history, we have seen attempts to make better languages to develop with than Verilog or VHDL. From community driven efforts to produce HDLs in more friendly software languages to HLS tools that attempt to translate normal software code into high performing hardware. Most successfully, we have seen the rise of domain specific tools that can create optimized FPGA designs for specific applications like machine learning.

These new tools and languages do make FPGA technology better as they can provide FPGA-level performance with much less development effort. Unfortunately, they are only able to do so in limited circumstances. VHDL’s and Verilog’s fundamental ability to represent circuits at the RTL level as well as widespread industrial support means that there is still a solid future for these languages. The best we can do as engineers is learn these HDLs, but also be open and willing to learn and contribute to these new tools. Doing so can help improve productivity and expand the FPGA community,

 

Andrew Swirski is the Founder and Managing Director of Beetlebox, a powerful DevOps software designed specifically for IoT, embedded, and hardware projects.

 

Author

9 Comments on “Can We Do Better Than Verilog and VHDL for FPGAs?”

  1. Why bother writing a lengthy article when everyone knows that answer is that no… we can’t do better than VHDL and Verilog.

    1. Hi, Aditya

      No, I beg to differ. In fact, over the recent years, Scala based HDL, such as Chisel and SpinalHDL start to get mainstream, as they come together with the rise of RISC-V.

      In fact my bet is on SpinalHDL + cocotb. And you can find the detailed reasoning for choosing SpinalHDL over Verilog/VHDL in the following blog post:

      https://fpga.pulserain.com/2023/02/limerick2-why-spinalhdl-history-of.html

      I have been designing with SpinalHDL for a long time, and I can tell you first hand that the SpinalHDL can boost your productivity by 2x at least, if you count how many lines you write for the same design in SpinalHDL vs those in Verilog/VHDL.

  2. Thanks for a nice, brief, overview of FPGA programming history. I suspect that looking closer at language development for what have become “standard” computers, we see the development from machine-specific assembly languages (every machine was different) to a couple high level non-machine specific languages with some focus on domain (i.e. FORTRAN, COBOL, RPG, etc.) to the more general non-domain focused languages that are popular today (Java, C++, etc.). “C” we can consider to be a “portable assembly language” which is pretty much as it was intended by Kernigan and Ritchie, but another branch to consider that is different from all of the above are the Lisp based languages which were more heavily influenced by the mathematics of computer theory (that is, recursive function theory) rather than the engineered constructs available at the time.

    While HDL was, as you say, developed as a way to describe RTL in a way that was easier to write and test (at least at the level of capability we had in the 80s), what we haven’t yet seen is a language that takes advantage of the theoretical underpinnings of what FPGAs really are: finite state machines. But there are a number of such languages (i.e. regular expression based) available for exploitation. I look forward to having such be used to specify general finite machines simply with appropriate debug tools.

  3. Python has been my favorite programming language since 1995 (Python 1.5.2). I also do quite a bit of Verilog coding, mainly for FPGAs, but occasionally also for ASICs. So I found the links from this article to various open-source HDL projects very interesting. One tangentially related project is cocotb (www.cocotb.org), which lets one write simulation testbenches in Python to exercise one’s Verilog/VHDL code. I found cocotb to be completely game-changing for simulating FPGA code in such a way that the output is actually checked (pass/fail); using Verilog to exercise one’s Verilog is fine is you’re checking the output waveforms by hand, but otherwise it’s quite tedious.

    I don’t find it at all difficult to write Verilog code, once I have a clear plan for what I want the code to do. But Verilog is a bit low-level for simply trying out ideas. I am tempted to try out one of these Python-based RTLs the next time I want first to code a high-level functional description of an algorithm, then somewhat adiabatically transform it into a cycle-correct simulation model, and then into RTL code, so that the first two steps initially facilitate thinking through the design details and then facilitate verification of the final Verilog code. I’m interested to hear from anyone who has succeeded at such an approach: using Python-based HDLs as a way to refine one’s specification so that one writes the Verilog HDL code just once.

  4. Designer of an Software Defined Radio here. So this question is bugging me for years now, and I have only partial answers. With my work on SDR I touched multilbe fields including VHDL, C, Matlab, PCB design, maths and information theroy, high frequency and general electronics design and simulation. I found that all these fields are very closely linked together in the design of an SDR.

    So you are constantly jumping between different languages, tools and toolchains. And simulating becomes a nightmare with increasing complexity. Maybe the problem is not that VHDL is imperfect, but VHDL is just a HDL. Maybe we need a mix/new type of language and toolchain that can handle the other domains also.

  5. The FPGA shortage forced us to look for alternates. Efinix was a natural choice. And while using Efinix products came across SpinalHdl as their SoC are derived from SpinalHdl SaxonSoc. Rather than customizing the SoC using Efinix IP catalog, which had limited functionality, we started using the SoC right from SpinalHdl and it was no turning back.
    I could say the lines of code is atleast 10x better. (And 100x if we compare the generated verilog code from Spinal HDL)
    I had made multiple representations to Efinix to promote SpinalHdl and be a game changer, but they want to keep their SpinalHdl dervative work closed.

    Kudos to Charles for his lifetime sacrifice to making our lives easy.

Leave a Reply

Your email address will not be published. Required fields are marked *