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.