Monday, January 21, 2013

Defining a good language Kernel

When you design a new language you have the ultimate freedom of defining how your language should look like. There are plenty of language favors available, each with their own set of advantages and disadvantages. As the language designer it is your ultimate goal to create a language that can easily be understood, learned and used. It should make common tasks easy but also allow more complicated cases.

A strictly procedural syntax seemed a bit to plain for me, a functional one too far away from the hardware. So my decision went for the so far most successful way, the object oriented way. But I did not try to create an academic overhead by forcing a full OOP way on the programmer. Instead I designed the expression syntax to be equivalent to the C/Java expressions and added a few OOP concepts where it made sense. This allows most programmers to get an idea of what is going on quite quickly. There are two additions to the known expression: Bit accesses designated with curly braces and concatenation of numbers with #.

Most statements also look quite a bit like regular C/Java code. But I had to add a few other concepts. Interfaces, generators and variable bit width integer and registers are among them. I will quickly explain them here and get into more details in a later post.

Interfaces are kind of like binding contracts for developers. If an interface is declared, the implementation has to have all those ports in this exact way that they are declared. This is really useful for communicating an API when the implementation is not known, does not exist yet or is in another language. For example if you want to instantiate VHDL entities, you have to declare their interface, which you can then instantiate. It is up to the developer to ensure that the interface matches the VHDL implementation. Another example are generators...

Generators are a very powerful concept to automatically generate code for you from a short description. To declare a generator multiple things are required. An interface which the generated unit will have to obey, parameters, which specify whatever code should be generated and an optional piece of code. The last part is what makes generators so powerful, you can essentially embed another language with it. Take the bus generator for example. From a few lines of code, it can generate you a whole lot of PSHDL code, C code and even documentation. But other use cases might include a processor with C code, a language for statemachines, a C to hardware generator Etc.

What I was not able to transfer over to PSHDL however is the semantic of C, a fully sequentially control flow as it is described with C. Instead, PSHDL took the path of other HDLs by having everything in parallel. If you need sequential execution, you will have to code a state machine. This is the tribute of programming FPGAs vs. programming CPUs that you have to pay. In hardware things are pipelined and running in parallel. The equivalent of functions are rather other ip cores, but to wire them up efficiently, the sequential paradigm had to go. To create efficient pipelines and state machines registers came into play. They allow you to create really fast and robust synchronous logic. This why they are an integral part of PSHDL. While on CPUs the width of int is chosen to be the most efficient for the given architecture, on an FPGA the developer has to decide how many bits his variable should have. Make it too big and expensive routing and fabric resources are wasted and timing will start to degrade.

Friday, January 18, 2013


The reason I created PSHDL is that I needed a language for programming FPGAs for my Phd. thesis. My thesis is about FPGA architectures, that is, the very low level architecture. So for example a question when designing FPGAs is: how many registers do I need? How much routing resourcesare necessary? What coarse grain hardware elements can help to improve performance?

To answer any of those questions benchmarks are essential. To create those benchmarks, I looked at various languages to check how easy it is to parse them and make sense of them. VHDL and Verilog, failed miserably. One problem in VHDL for example is that it is easier to create a latch by chance than it is to create a properly described register. There are like a million ways to create a register and even more to describe something that looks like a register, but in the one tool is one and in another it is not. But registers are the building block of every piece of hardware. Another problem is the simulation/hardware mismatch that makes it difficult to validate your results. Do I need to mention that VHDL is very hard to parse as well?

After I looked at the options, I decided that it would be a good idea to create my own language. It is not like there aren't a gazillion other languages with varying focuses, but I thought: lets create one that is truly fun to use, with proper IDE support and all that fancy tooling that you're used to when you program something except HDLs. That is why I created my language in XText. From a very sparse language description it not just creates a proper parser, it also creates an AST (abstract syntax tree that represents the input as a tree), but also a quite nice tooling for eclipse.

In the meantime I also created a web interface. The idea is that it allows interested people to take a look at PSHDL without the need to install anything on their computer. After a while I realized that it can be more than just a toy, and this is what I am aiming now for.

Welcome to PSHDL

In this blog I try to outline my motivation for the creation of PSHDL, which by the way stands for Plain Simple Hardware Description Language. As the name itself already suggests, a great emphasis had been put on creating a language that is easy to learn and fun to work with. Unlike VHDL which I hate with a passion. So expect many rumbling rants about VHDL here. If you're thinking: good, I am programming Verilog, well I think that Verilog has the same problems in most cases, so it is just slightly better than VHDL, but not enough to make a difference.
If you have any feedback about PSHDL, don't hesitate to contact me. It is far from being perfect, but every bug report I get, helps to improve it.