Low-Level Horror

This period I’m taking a class called “Technology for System Realization”. It’s a class where you learn how to create chips. You learn to use VHDL to design chips that accomplish a particular task. VHDL is a programming language with a pascal-like syntax that’s set as a standard to design and implement chips. What kind of chips? Any kind. Processors, DSPs, Analog to Digital converters, anything.

The class practical assignments started out simple. One of the first assignments was implementing Kitt-like lights (like on the Knightrider). In other words on 8 LED lights, we had to light up three which bounce from left to right. This was actually not that hard, you just have to create a state diagram, figure out a way to encode your states and then wiring all the needed flip-flops and in/out ports together and putting in some and-ports and or-ports. It’s about as low-level as you can get, next to actually creating your own condensators.

If you know a little about me you will now ask yourself why the hell I’m taking this class. Good question. I’m all high-level, the higher the level of abstraction, the better. Why this major dive down? I could tell you all kinds of stories about how I think that if you’re programming on a high-level you should also know about the low-level. And of course, that’s kind of true, but the actual reason is that it’s in my master programme. I chose for the System and Software Engineering master, thinking that with the “System” part they’d just mean large products. But apparantly, they mean this very low-level self-contained chip kind of programming. But all in all, it was quite interesting and fun.

Until this week. In the latest assignments we had to test our implementation using an FPGA, which is a kind of a programmable chip. Usually you have chips baked on a piece of silicon and can’t change it after it’s produced. However this FPGA can be loaded with a bit-file which tells it exactly which input ports have to be connected to which ports and wired through to which flip-flow onto which output port etc. If your VHDL code is right this is really fun. I could actually see the Kitt lights bounce on the 8 LEDs. However, this week’s assignment was a tad harder. First we had connect a serial port from the development PC we use to the FPGA (which also has a serial interface) and let the things you send to it be printed on the little character display and be heared by a sound part that can be connected to the FPGA. Doesn’t sound too hard eh? How many lines of code would that take in Python, or even in C? Not that much.

Let me tell you, this week we spent like 18 hours on getting a UART to work. A UART is a component that converts serial data into parallel data, sounds simple? The concept is, getting to work is different. First, there’s a lot of fiddling with baud-rates and parity checks. Secondly, there’s the protocol you use to communicate with the UART component. The UART was implemented in VHDL and can just be used from our code. But no matter how much we tried, we couldn’t get it to work. The data we entered on the keyboard arrived at the FPGA and UART, but for some reason there where all kinds of errors occuring. For example, every time you sent the charachter ‘a’ it would show a different (ASCII) bit pattern at the output of the UART component. It’s sooooo frustrating!

I admire people doing this kind of stuff as a daytime job. I’d never want to work on a company like Intel or AMD.