Thursday, February 24, 2005

How I'm doing it

Step 1 was to prove to myself that it was all possible.

Sure, I know that any digital computer can be built from the simplest gates [with some restrictions--I'm being approximate here]. That doesn't mean that I personally can come up with a reasonable design in finite time. As it turned out, this became one of the many design projects that I would pick up now and then, think about for a couple of months, and then put down for a couple more. I would frequently decide, "But what if, instead, I optimize for {ease of opcode decode, size of instruction, quantity of routing logic, etc.}?" and start from scratch again.
One day, after about 4 years of this, I decided, "There are a lot of ways to do this. I should just pick one". The architecture and instruction set were done one week and 30 pages of notes later.

At this point, the project had gotten further than any of my other design projects ever had, so I decided to proceed to:

Step 2, in which I write a CAD tool, which I call Ball Computer Designer [bcd for short], to enable me to test out designs. Sure, I could have gone straight to physical construction, but as a software engineer [and someone who's helped tape out chips] I feel strongly that the best way to experiment is in simulation. Plus, who's going to offer me funding to build the sculpture, and a place to put it, without some proof that I know what I'm talking about? OK, so it's also possible that I could have adapted an existing CAD or simulation framework from electronic to ball logic, saving myself a whole heap of coding, but where would be the fun in that?

Now, two additional years later, I now find myself the proud owner of 15000+ lines of C++ and 200+ lines of feature requests and bug descriptions. However, the tool is now Good Enough to start using, and so I proceed to:

Step 3, in which I will design and test the actual gate-level logic of all components of the CPU.

So far I've been quite pleased with how easy it is to put the components together. My first attempt was a 4-bit proof-of-concept ALU, which could add, subtract, and, or, and xor [no overflow/negative/zero/carry checks in or out yet]. After that, I decided to go straight to full-scale components, and I've done a few of them in as many days. That's days of actual work on the project, unfortunately, not calendar days. I only get to work on this in my Copious Spare Time™.

However, that being said, I've decided to start sharing what I've got, and hope to be updating this blog at least once every two weeks. I'll be posting reports on my progress along with images taken from bcd. They're not screen shots, since most of the designs don't fit on one screen. Also, because the GUI library I'm using doesn't support writing images to files, I'm using a different one to write out the PNGs for this blog.

After much struggling to try to get the PNGs to look good, I've determined that FLTK uses Xft for fonts, and GD uses FreeType fonts, and never the twain shall meet. So the PNGs are a bit uglier than what I'm actually seeing at home; I'm sorry about that. If you know an easy way to fix it, please do let me know.

For future reference, Step 4 is writing test software to verify the design, Step 5 is prototyping and testing the physical gate designs and the structure needed to hold them all in place, Step 6 is to produce a total cost and time estimate for construction, and Step 7 is to find someone who wants one built. I think it could be both
  • a terrific way to teach kids how computers work.
  • wicked cool.

Next

1 Comments:

Anonymous Anonymous said...

* a terrific way to teach kids how computers work.
* wicked cool.
Yes, especially the latter. :-)

--Michael (aka catzen)

11:32 PM  

Post a Comment

<< Home