I like to spend at least some time every year indulging my inner hardware engineer, working on something that involves actual physical things you can touch, and preferably even solder. It’s usually not something practical, but it seems always to be a satisfying change of pace from my day-to-day software duties. Call it getting in my required flight hours for maintaining my Nerd/Hacker status maybe, or perhaps it’s for keeping the “Mad” certification, I don’t know.

This year has been no exception. I mentioned in my first post this year that I had picked up a BASYS 3 FPGA board, and was planning on experimenting with it. A Field-Programmable Gate Array (FPGA) is kind of a grey area between hardware and software since it is software-programmable hardware that does not in fact require any soldering. I still count it against my hardware nerd flight hours though — even though in truth I’ve spent most of my time simulating circuits and not even downloading them onto the board.

FPGA for Hire, Problems Wanted

So the question then became, what to do with this thing? In the past I had spent a lot of time playing with small embedded processor boards, like Arduino or Raspberry Pi, building everything from a talk box for my dog, to a retro-arcade system for my living room. This BASYS beast was different though because it allowed one to create hardware circuits at a very low level, inside the programmable fabric of the FPGA chip.

I wanted therefore to build something unique, something that took advantage of the fact I had fully-customizable hardware here and not just an existing processor.

And ay, there’s the rub, as Hamlet put it. The mere fact I could simulate any circuit I planned to download to the BASYS meant that I could also write that same algorithm as software for an existing system, like say a Python program running on a Raspberry Pi. Probably quicker. Probably easier. And probably with the same (or better) result.

This was a rub that unfortunately not only vexed me, but also the makers of programmable hardware chips, like Xilinx and Intel/Altera.

Who will buy your product if it is harder to use (and usually more expensive) than another solution? Cheap and easy-to-use processor-based systems like Arduino and Raspberry Pi have become increasingly more prevalent and capable over the past decade, cutting into the programmable hardware business.

The answer to why you would still want to build an FPGA system is (and always has been) speed. If you can describe your program/algorithm in Verilog or VHDL instead of Python, then you can implement it natively in hardware on one of these boards and it will run blindingly fast compared to a software implementation.

Python for instance is known not to be a speed-demon, and even a simple addition operation there results in multiple, perhaps dozens, of instructions. And each processor instruction can require multiple clock cycles to complete. A hardware implementation can do that same addition operation in one clock cycle.

The BASYS 3 board I have is over 10 years old and is used primarily for educational purposes. Countless Computer and Electrical Engineering undergrads have probably programmed one. Its max clock speed is 450MHz, way below that of any modern processor. But in most circumstances, an algorithm implemented on this old machine could still run circles around a Python program, running on the fastest CPU out there right now.

Problem was that I didn’t have any potential project plans that required that much performance. Nor do a lot of others, which leaves companies like Xilinx and Altera in a bit of a bind, and looking for new markets. They have been moving lately into areas like specialized hardware for machine learning, which I think is a smart play since it really is an area that has an almost limitless need for customizable, high-performance hardware.

Psychic Treble Damage

So I quickly gave up on creating something that could only exist on my FPGA board, coming to terms with the idea that this project was about the doing, not so much the result. It seemed like it would be good enough to just create something one-of-a-kind, with the satisfaction of knowing it is the world’s only flurb, or zoingle, or whatever.

But given the size of the world, this also turned out to be harder than it sounded.

I’ve long had this thought of building my own oddball processor and accompanying software stack from the ground up, and deliberately eschewing any kind of existing standards. No ARM core, no C, no GNU, no USB, no Unix. Everything created new, custom, and stubbornly incompatible with the rest of the world.

Building on existing standards and not re-inventing the wheel is of course the foundation of good engineering practice. There is very little monetary incentive in redoing things someone else has already figured out, and doing everything yourself forces one to work at a low level instead of “standing on the shoulders of giants”. So it is rarely done, unless there is a promise of discovering some new path forward with fundamental benefits. Frost’s proverbial road less traveled by.

I began to have somewhat grandiose visions of building a processor and software language of my own, that would be capable of implementing say a video game of some sort. Everything along the way new: Instruction set, compiler, low-level software, and game application. Who knows what I might discover along the way? I began to research this idea to see if anyone had done it, and was crushingly disappointed to find a lot of excellent “prior art” here.

Almost every place I’ve worked has had a legal department that strongly cautions engineers against attempting to research whether some innovative idea they have has already been done. The reason has to do with patent law, and something called Treble Damages. The basic idea is, if you violate a patent belonging to another company, they can sue for damages. It can often happen by accident, when people independently happen to arrive at the same solution to a problem.

But if you knowingly violate someone’s patent by copying it, that is another level entirely. Your company can be liable for additional punitive “Treble” damages in this case. So in order to keep “plausible deniability”, it is important for there not to be some electronic trail showing you knew something had been patented but decided to violate that patent by creating an equivalent.

I didn’t really have any patent law worries on my hands here. This was a side project, not work-related, and not something I planned to sell. But to find out that someone else had already created an impressive custom FPGA-based CPU, compiler, language, and accompanying game all on his own was devastating Treble Damage to my motivation. I didn’t really picture myself doing a better job than this guy, or even getting anywhere near as far as he did.

I then thought about doing a super, super custom FPGA project, whereby I create a video game, entirely in Verilog so it can be implemented in hardware directly. A video game without a processor involved - it seemed like crazy talk! Until I found multiple people had already done it. In fact, I found a guy who made a game on the very BASYS 3 FPGA board I was using.

And the more I looked, the more FPGA-native video games I found. Like this one. Or this one. It was clearly a sweet spot for FPGA usage, but it didn’t exactly seem like an interesting unexplored area, so I gave up on pursuing this idea as well.

My last thought was to go back to my roots, and try to do an FPGA implementation of the Digital PDP-8 minicomputer I learned to program on. I happened to have a set of original PDP-8 schematics, so it seemed I could try to build one using them as a reference.

But you probably can guess — this is also something that has been done multiple times. A project so common in fact the PDP-8 is an official library in OpenCores, the Open Source Hardware IP site.

Nothing is New but You

Now that I had caught up a little with what the rest of the world had been doing with FPGAs over the past 15 years while I wasn’t looking, I changed my thinking.

What I finally arrived at was the thought that I should not be worrying about doing something unique to the world. It was good enough for it to be unique to me. Lots of people had designed their own CPUs. But none of them were me.

It is a somewhat common capstone project for computer engineering students for instance to do some processor FPGA implementation. But not when I was an undergrad, because FPGAs did not even exist then. My first job out of college was actually working on a team designing a mainframe computer. But my job then was to design the memory system, not the CPU. And later, I worked on debuggers and simulators that frequently required me to interact with hardware designs of complex new CPUs. But always reading and debugging design code, not writing it, or even understanding how it works.

So I went back to the original plan, to finally design a CPU of my own, with no further goal other than to do it. But since I still didn't want to just mimic some existing architecture, I promised myself I would do weird, experimental things with the design when I could.

I was generally free from constraints, like needing to have a certain performance, to be commercially viable, or to be compatible with any existing thing.

So I started my journey on the less-taken road by making a nine-bit CPU. Why nine bits? Well, there's a healthy dose of “why not?” in there, but it also had an appealing “three of three” symmetry to it.

The big reason though is that it pretty much guaranteed it will not be very standard. Maybe there are other nine-bit machines out there, but if so it's not a large number. It is not that practical, for reasons I will go into in the next part of this series. But practical was also not on my list of design considerations, so I went ahead and sketched out an instruction set and architecture, and built a starting version of this machine.

The first Standards casualty of this 9-bit decision I encountered was bytes. No eight-bit quantities, no bytes. So I had to come up with a new term. Old mainframes and minicomputers with octal data sizes like 12, 18, or 36 bits just called their data quantities “words”.

The QIXOTE-1 (my working title for the CPU) is also an octal machine, given you can nicely fit 3 three-bit octal digits into 9 bits. But calling the 9-bit quantity a “word” seemed boring. So I did some research and discovered to my delight that a collection of nine of something is called a Nonad.

So the QIXOTE-1 is shaping up to be a fully-nonadic processor, and currently features two kilononads of memory! Satisfyingly weird, already.

I soon found a lot of really useful hardware and software things that just can’t be used, once you decide to build a nonadic system. And so you just have to then create a new and unique version yourself, out of necessity. And I guess that is the biggest motivation for going this way.

QIXOTE-1 has only run a few programs so far, but I have already learned a lot about what goes on behind the scenes that I’ve been taking for granted, all these years.

Well, I guess this kind of covers the “why” part of the project, which is where I would like to end for now. In the next installment, I’ll talk a little more about the QIXOTE-1, and the (hopefully interesting) things I’ve learned about CPU design in the process. See y’all back here for more nine-bit nerdiness then!

Explore Further

Next Time: We dive deeper down the nine-bit rabbit hole and take a look at QIXOTE-1, with a few lessons I learned about how to design a CPU. And a few about how not to. Nonstandard fun returns in: Holy Nonads, Part 010!

The Mad Ned Memo features nerdy tales and discussions from the world of computer engineering and technology — past, present, and future. Follow the link to see more, and if it’s your kind of thing, consider subscribing! You’ll get the Mad Ned Memo delivered to your inbox on a weekly basis, and never miss an issue. It’s cost-free and ad-free, and you can unsubscribe at any time.

The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.