Job: Kindergarten Teacher

During my first two weeks in Zuid-Holland, I didn't have regular internet and wrote a lot of posts on my laptop. I have now run out of posts. I've been a bit busy with VHDL the past few days (yesterday I checked roughly 15,000 lines of VHDL into our repository! 14,900 of these lines were code-generated test vectors, however, so I'm not really that productive). Anyways, I don't really have a great post ready, so I'm going to give a high level overview of VHSIC hardware description language (VHDL), a language I've had to use at work recently. This post is geared towards non-technical readers - most of my university friends have taken a processor architecture class which requires the use of a custom hardware description language similar to VHDL.

Nearly all software languages are serial, meaning they completely execute one instruction before starting on the next. Statements have a linear structure, such as:

get out of bed
eat breakfast
clean dishes
check RSS reader for Oog Robot posts
take shower
brush teeth

The correct output of the program relies on the statements being executed *in order*. A reason that computer programs were originally built like this is that sharing is hard. Even in the example above, someone wouldn't want to take a shower while another person was washing dishes. Well, at least in my apartment there would be little reason to sing in the shower.

In contrast is a completely parallel model of execution. In a parallel model, everything occurs at the same time. A simple analogy is a woodworking assembly line and a carpenter. Serial programs are like carpenters - only a few things can occur at a time. I say a few because a good carpenter might cut one piece of wood while she waits for the varnish to dry on another. At the end of the day, however, there is a limit to how many things one carpenter can do.

Parallel programs are like assembly lines, as work can scale with size. While assembly lines can do a lot more work, they are not as easy to set up. The amount of coordination must also scale with the number of workers. The output and input of subsequent stages must match in attributes like volume and timing, or else mishaps such as pile-ups start to occur.

For a concrete example, say we want to make a peanut butter and jelly sandwich. Here are the steps at a certain level of detail:

Take out plate
Take out bread
Take out PB
Take out J
Take out PB knife
Take out J knife
Spread PB on bread with PB knife
Spread J on bread with J knife
Put away bread
Put away PB
Put away J
Put away PB knife
Put away J knife
Put bread together

In a serial program we have to make sure all the instructions are in the right order, and place these instructions in order. In a parallel program, however, we can leverage the fact that some things can occur at the same time. We could have a "bread factory", a "PB spreading factory", a "J spreading factory", and a "sandwich from pre-spread bread factory".

Bread factory:
Take out bread
Give out bread on request
Put away bread

PB spreading factory:
Take out PB
Take out PB knife
Get bread from "bread factory"
Spread PB on bread
Pass bread w/ PB downstream
Put away PB
Put away knife

J spreading factory:
Take out J
Take out J knife
Get bread from "bread factory"
Spread J on bread
Pass bread w/ J downstream
Put away J
Put away knife

Sandwich factory:
Take out plate
Take PB-bread from PB factory
Take J-bread from J factory
Put slices of bread together

Thus the factories can work at the same time. The sandwich factory and J-bread factory can be taking out plates and J, respectively. Note that while we have more instructions overall due to coordination (and I've even skipped some coordination instructions), each of the specific units is much simpler than the entire program. Understanding a complex system requires breaking down functionality into smaller chunks. Serial programs also aggregate functionality for understandability in a similar way.

As computers evolve it will be interesting to watch the two types of programs evolve. The speed of computer processors has not increased much over the past few years. Processor manufacturers have started to put multiple sets of older, single processors (called cores) into their fancy new processors. Small modifications to serial programs can easily take advantage of a few of these cores, but major modifications or complex procedures are required for serial programs to take advantage of a lot of cores (more than, say, 16).

Anyways, I work with field-programmable gate arrays (FPGAs), which require parallel programs. I'm writing software and coordination routines which allow a light sensor (like your eye) to talk to a display. One can implement serial programs, but one must write a parallel program with complex signaling to do this (or take a freely available one). Thus a good statement of my job is that right now I'm coordinating interactions between a bunch of components. Except the components are like my red-headed stepchildren, and they really don't want to talk to one another. Especially that ones that aren't supposed to be talking to one another.