Hacker | Engineer

I came across MyHDL recently, and I must say I’m quite impressed. It’s very much along the lines of Computer.Build, providing a way of defining hardware in Python, and generating Verilog code from that. It uses Python’s ast module to manipulate and analyze your source code, letting you write pure Python and get back Verilog. You do need a handful of special decorators to tell the compiler what’s going on, but it can mostly figure things out.

The downside of the true AST approach is that it takes a lot of code. Thousands upon thousands of lines of code to recursively descend the AST and deal with the Python language. At least he didn’t have to write a parser, but there’s still a lot of work required when compared with an internal DSL like Computer.Build. For the Ruby side, I’m taking advantage of Ruby’s blocks and metaprogramming tricks to build an internal DSL with minimal effort, and Clojure lets me jump straight to my own language thanks to its Lisp syntax.

Besides being easier to implement, Computer.Build is focusing on a different domain. It’s not intended to support general-purpose FPGA development. Instead, it’s going to be a toolkit for building computer-like devices, with an instruction set and clock and all that jazz. As such, it doesn’t need to support nearly as much of any language as MyHDL does. I’m still working out exactly how much Computer.Build needs to do to support the design of microprocessors, but honestly I think it’s pretty close now that I have state machines working.

If I were starting from scratch on this project and focusing strictly on the FPGA target, I probably would have built this from MyHDL now that I know about it. Since this project is as much about Ruby vs. Clojure as it is about hardware development, I stand by my choices. MyHDL is a very cool tool, though.

I met with my advisor for the project, Mukkai Krishnamoorthy, today to officially kick off my independent study this semester for Computer.Build. We mapped out some milestones, discussed some implementation ideas, and went over a couple of books. It’s time to get started for real.

I’m already making significant headway, with some basic VHDL code generation from both Ruby and Clojure and a simple multiplexer implemented in each. I’m about half way done building the state machine generator in Clojure, and once that’s finished the Ruby version shouldn’t be too much more work. I think the milestones we came up with are pretty solid, and I’m sure I can get things done on time.

My advisor suggested that I focus on getting most of the code written before the middle of the semester, so I have the rest of the time to test, tweak, debug, and write. I think this is a great approach, and the schedule we came up with to fit it seems quite doable.

Milestones (divide and conquer)

• 1/4 done (February 21): State machines working in both languages, and plan for implementation of computer generation
• 1/2 done (March 21): Simple computer successfully generated
• 3/4 done (April 18): TBD
• end of semester (May 16): Paper written comparing the two implementations, and a computer generated from each running successfully in an FPGA

Books

The Elements of Computing Systems: Building a Modern Computer from First Principles

This book got me really excited. My class this semester on Advanced Computer Hardware design requires no books, so I had no idea this even existed. It pretty much walks through the entire process of building a computer, all the way from gates to operating systems. My advisor let me borrow it for the entire semester! This is going to be a great reference and resource for figuring out how to put the pieces together.

Programming Languages: A grand tour

When I started talking about language stuff, which half of this project is, my advisor jumped up and started looking for his copy of this book. He couldn’t find it, but it sounds like a pretty useful thing to have. It’s basically a collection of all of the major papers about programming languages in the last few decades.

A friend of mine pointed me toward a wonderful Master’s Thesis about using Bluespec SystemVerilog (BSV) to develop an H.264 hardware video decoder. The introduction provides a clear overview of why C-based reference designs fall over for things like H.264 encoding/decoding, and the body of the paper demonstrates how to apply BSV to serious problems.

My professor in Computer Hardware Design this semester, when asked about BSV, dismissed it with something along the lines of “kids invent new HDLs all the time, but real men use VHDL or Verilog.” I’m getting the impression this is a prevalent believe in the electrical engineering world. Instead of moving forward and developing better and better tools, electrical engineers get stuck with old technology that is rarely optimal for the job. Things like BSV come along with the potential to completely change the market, but nobody notices because they’re too busy solving the same problems over and over again in lower-level languages.

Bluespec SystemVerilog provides some of the kind of abstraction I’m going for with Computer.Build. It’s a great tool, and I’m totally using it for Advanced Computer Hardware Design next semester. Unfortunately, it fall short of supporting metaprogramming. Why in the world would you want metaprogramming with hardware? For the same reasons you do it in software! Syntactic abstraction makes problem and solution definitions more concise and closer to the actual problem domain. This paper talks about exactly why this is crucial for H.264 decoding, but it applies everywhere. The C implementations just pass around huge shared memory structures, but this isn’t how the actual process of H.264 decoding works. BSV provides some great abstractions that get much closer to the problem, and for this application may be the best tool for the job.

I’m going for even more with Computer.Build, though. My goal is to allow the development of a multitude of DSLs for defining different kinds of hardware. For one-off solutions, you’re probably better off with BSV, but Computer.Build is intended to solve entire classes of problems in a manner only doable with DSLs or some other kind of language-level abstraction.