Tuesday, April 2, 2013

Why VHDL sucks

I am quick to say that VHDL sucks and some people argue that it is without substance. Some even argue that there is nothing wrong with VHDL. So I want to write down the points that made me come to this conclusion.

First of all, there is no reason to get offended, if you like VHDL and want to use it for everything, please continue to do so. You put a lot of effort into learning that language and I am not going to take that away from you. This is just my opinion and based on the fact that I care about getting FPGA designs done.

Problem #1: VHDL is a very capable language

VHDL has a lot of functionality built into it. Why is that a problem? Because it can become very confusing very quickly. Consider a natural language like German. It has many ways to express the same problem in different terms, which is great and fun because you can put your emphasis on different things, but there are also dialects. If you're not used to the lower german, the bavarian, the swiss german or any other german dialect, you will have a hard time to understand it. The ability to express the same problem in so many ways comes with the disadvantage of being able to make code less readable for others. This paper VHDL Synthese Vergleich describes a "novel" way to describe hardware in SW terms. It also mentions that it comes with price of reduced portability. Yet it is still valid VHDL.

With great power comes great responsibility. In VHDL you will have to constrain yourself to not use any uncommon syntax constructs. Not an easy task when you're learning it and there are 97 keywords to choose from. (C has 32, Verilog 103, PSHDL 31, Java 50, C++11 84). This is even further complicated by the 2 domains that VHDL is used in.

Problem #2: Usage domains

You can vaguely split VHDL into 2 domains. The simulation, where you can basically use everything the language has to offer (if your simulation tool of choice has implemented it). The other is the synthesizable subset. What constitutes the synthesizable subset of VHDL is defined by IEEE 1076.3 and by what your tool vendor thought might be possible and useful to implement. Especially the last part is what makes it so problematic. Some vendor tool might be able to synthesize some part correctly (as in the way the programmer intended it to work), while others might produce a different result.

As the VHDL simulation subset is significantly bigger than the synthesis part, newcomers are often confused by the choice. When you google some code, it is hard to immediately recognize whether it is suited for synthesis or not. It is also extraordinarily easy to create code that works in simulation but does not work in HW and vice versa. But the worst code is the one that works in simulation and only works most of the time in reality, for example when latches or race-conditions are created.

Problem #3: Old language

VHDL is an old language. Why is that a problem? Because a lot of people are coming from the software side of things, so VHDL is very likely not the first programming language for most of them. If you look at most procedural/object oriented languages, you will notice that the expression subset is C style. So when people see code, they put their pre-conceptions about what a language does into what they read. But VHDL being Ada based has a few traps that people can easily fall into if they are not 100% familiar with it.

But to back up a little bit, VHDL was invented to document ASIC designs. Then people realized that it could be used for simulation as well. And even later they discovered that you can use it for synthesis. This makes it very clear that synthesis is an afterthought of VHDL and explains why it is so damn easy to create a simulation/hw mismatch.

VHDL synthesis forces you to obey certain pattern so that the synthesis tools can detect those patterns and infer what you were describing there. If you make a mistake you are lucky when you get a meaningful error message on why that pattern didn't match. If you're unlucky you will simply get a bit file that fails to work as expected. If you're really unlucky you will get a model that only fails on certain conditions.

Problem #4: Tooling

Because VHDL synthesis is based on pattern detection, it is very hard for an editor to provide useful feedback to the user. If you look at the most advanced editor for VHDL that I know of, the Sigasi HDL Editor, you will notice that the errors you will get are not the same as the errors that the synthesis will provide. This is in part because Sigasi can't know whether you are designing with simulation in mind or for synthesis. If you're designing for synthesis, it can't also know what the vendor tool will eventually accept and what not and whether what you get is what you expected to get. The vendor tools on the other hand have absolutely no support for what a modern development environment provides, like VCS, instant error markers, quick fixes, templates, history comparisons, refactoring etc..

Additional issues arise by ambiguities in the language itself. a(9) for example can mean different things. It can be the access of the 9th index of a variable/signal/constant named a (also it can be the MSB or the LSB), it can also be the invocation of a function/procedure named a with the argument 9 or it can also be the access of the 9th index of parameterless function. In order to provide useful feedback for the user, a lot of context has to be known. Parsing VHDL is considered VERY hard by many people. Here someone tried to implement a bison based parser. That the language itself is hard to parse does not really help to create a better tooling. Fun fact: The reason why I started PSHDL is because I considered the idea of parsing VHDL and making sense of it a too big waste of time.

Problem #5: Verbosity / duplication

Because VHDL is based on ADA, you will find all those nice keywords that make up the language. Those are not exactly what I mean by verbosity, although it certainly does not help. What I mean is that when you want to instantiate something, you will have to declare a local signal (and duplicate its type information) that the entity can connect to and then declare the port mapping. If you're using component instantiation for some reason, you will have actually have 3 lines that you need to add/change per port. Also one of the recommended pattern for describing state machines is to use 3 processes. Each process repeats the same switch with all enums. Btw. chances are that unless you know blocks, you will have a large distance between your enum declaration and the actual usage. If you add a state, you will have to add it in 3 places. Even if you just have 2 processes (most of the time you will not be able to have less because you don't want everything to become a register), it is hard to see what is going on in a big state machine.

Problem #6: Describe what you want vs. just telling what you want

If you want to have a register in VHDL, you will have to describe behavior that works like a register. One little mistake in its description and you will get something different entirely. Verilog has a slight advantage here in that you can make a contract by saying: Beware compiler, I'm trying to describe a register here! If the result is not a register, Verilog does warn you about it. Not so in VHDL. The earliest moment you will notice that your precious register is a dull latch is when you look at the synthesis report/ warning section. The warning section on the other hand gets very crowded very quickly, and it is easy to miss some important ones.

Problem #7: Learning curve

In our university we are teaching students VHDL and we can see how they are learning. Most of them hate VHDL (and the tooling) after that class. VHDL is very frustrating to learn for all of the reasons listed above. Most people get frustrated when they are starting with programming FPGAs because learning VHDL, the idea of how to program HW and the tools at the same time is such a steep learning curve.


PSHDL is a drastically simplified version of VHDL with a modern syntax. This allows developers to carry over their prior knowledge more easily. It also avoids some of the most commonly observed pit falls that students make when they learn VHDL. It is also designed with advanced tooling in mind and I am eagerly working on making PSHDL a joy to use without having to install gigabytes of tools.


  1. Although I admire your effort in creating a language to scratch your own itch, I think the solution you propose only address a fraction of the challenge of digital design.

    Problem #1 and #2

    These are two sides of the same case. The capabilities of the language is what makes it useful in the two usage domains: Synthesis and simulation. It is certainly true this can be quite challenging for new engineers, but the advantage of being able to do both design and verification becomes quite obvious once you get past the initial threshold. The alternative would be to create your design in one language - say PSHDL -and then do the verification in another. This would add an additional impedance matching layer between the implementation and verification language.

    Problem #3

    C is an old language. Nobody's complaining about that. But to be serious, being different to more common languages actually help differentiate from sequential programming languages such as C or Java. Looking like C or Java does not make it any easier to understand the parallel nature of digital hardware.

    Problem #4

    Tool support is certainly a challenge. Vendors usually only support a subset of the standard, but without demand improvement will not happen. The tools I use every day has support for the majority of the missing features you mention. We use git for version control, Sigasi gives me basic refactoring and error highlighting, and so does Riviera PRO. The world is not that bad.

    Problem #5

    The duplication is a lot better in later versions of VHDL. Components are usually not needed, but you need them, just like you do in PSHDL when you want to use VHDL entities, if you want to do mixed-languages designs. A rather powerful feature if you ask me.

    Problem #7

    The learning curve is not unique to VHDL - it's a property of digital design itself. Give your students SystemVerilog, and I'm sure they'll be confused too. But the problem of digital design and verification is not an easy task. It takes a broad skill set, and years of experience to master.


    VHDL is not perfect, but it's a capable tool for solving the two tasks involved in digital design: Create an architecture that can be implemented in digital gates and registers, and verify that it behaves according to the specification. According to the examples I've seen on your website you try to ease the first part, but there is nothing regarding verification. Industry data shows that the vast majority of development time is spent in verification, and not RTL design. Students need to learn the capabilities of their hardware - and therefore the synthesisable subset of VHDL or Verilog - and the full power of the language to enable them to do efficient verification of their designs.

    1. Regarding Verification:
      Verification is a big issue and I clearly see that. But I do tackle it in a different way. If you take a look at the test-bench example on pshdl.org, you can see that you can indeed write simple test benches in PSHDL. (asserts and printfs are on my to do list)

      But the problem in verification is not to rewrite the problem in a different way in the same language, and make the same mistakes slightly different, but to feed meaningful data into the system.

      When you do something like implementing a video codec, you would probably take a look at the reference implementation and see what parts could benefit from putting it into hardware.

      A little side example: I implemented a de-bayering video scaling core and I wanted to test it with data from the camera. What I had to do was to retrieve the camera data, dump it into a file, then read that file in the VHDL test-bench, process it, dump it into another file, and write a converter to see if I was successfully doing what I intended to do. This process inhibits you from testing many different cases because it is very cumbersome.

      PSHDL is addressing this issue by providing a simple byte code. This byte code can then be run by an interpreter that is written in whatever language you are working in. (I currently have Java and a student is working on C/C++). With this you can take the Java program to collect the data and directly feed it into your HDL code and directly output it, without having to resort to intermediate files and additional tools that you need to learn. All of the IP Cores that I wrote have nice JUnit tests that I use for ensuring that they are behaving as intended.

      Personally I think that writing the verification in another language is not a big deal. If at it all I see it as a big plus, because you can leverage great libraries to write more extensive test cases.

      Regarding learning VHDL:
      A very common false friend that I find in students code is the for loop. Most of the time it is used falsely on the first try. But the worst thing is that the behavior might work out as intended in the simulation. So VHDL, especially the sequential statements are not too far from C stuff to be truly a reminder that VHDL is significantly different from C. Unlike functional programming that indeed is truly different from OO especially in the pure functional languages.

      Of course you need to learn that HDLs are note another procedural programming language, but making it extra hard with an unfamiliar syntax, strange error messages and crappy tooling is not easing that curve.

      Regarding tooling:
      Having to learn multiple tools is not a very good idea. You may know that I think highly of Sigasi, but it is rather useless for me as the warnings are not the same as the ones I get in Xilinx. Some code that I write shows no error in Sigasi, but has plenty in Xilinx, while Actel accepts it happily.

      When you love VHDL, keep using it. PSHDL is for those that want to learn hardware design without having to spent a lot of frustration on learning VHDL and the tools. If they are serious about it, they can learn VHDL later on anyway. Although PSHDL is much more capable than you probably are aware of, I am not going into the big business where the money is at. I am aiming at the hobbyist, just like Arduino does.

      In the mean time I am using PSHDL to write really powerful transformations for TRM, SHP and other shenanigans :)

  2. This comment has been removed by the author.

  3. VHDL is a nightmare ... I just hate it especially after working with Verilog!