What does it take to design and build your own processor? This series of posts serves as a retrospective and documents my descent into the depths of computer architecture and digital design.

Links to the other parts of this series:

• Introduction
• Defining the Architecture (Coming soon!)
• Instruction Set Details (Coming soon!)
• Behavioural Model (Coming soon!)
• Implementing the Microarchitecture (Coming soon!)
• Verification (Coming soon!)
• Conclusion (Coming soon!)

Objectives

An Instruction Set Architecture or ISA can be thought of as the interface between the hardware that implements a design and the software that runs on it. This includes things like the list of supported instructions, the number of registers available, how wide they are, and so on. An example of an architecture would be RISC-V, which is largely unique in that it's free and open-source.

The microarchitecture describes a specific implementation of the architecture, or what actually gets implemented in the HDL and etched into silicon to form the final chip. An example of this would be Hazard3, the RISC-V processor in the RP2350 by Raspberry Pi.

My goal with this project was to design and implement my own ISA and have some kind of physical implementation of it actually running programs written in its own assembly language.

But Why?

The main reason for wanting to do this is that it's extremely compelling! While studying at university I took the Advanced Computer Architecture module, which culminated in each student implementing a cycle-accurate model of their own superscalar out-of-order processor. I really enjoyed this, and have been wanting to go back and do it "properly" ever since, especially after having gained some real world experience in the field.

Personally, I also find that while understanding the theory is important, the only way to truly get to grips with a concept is to have a go at using or implementing it. Even things that I thought I understood very well often had surprisingly intricate details and edge cases that I hadn't considered until I dived in and got my hands dirty, so I think there's definite value in going through the whole process from start of finish yourself.

This is also why I didn't want to implement a RISC-V processor, even though it would have been easier and saved me considerable time on things like tooling. While it still would have taught me a lot about microarchitectural design decisions, I would be completely unaware of the trade-offs that you need to make when designing the architecture itself. And yes, I know they justify many of the architectural decisions in the RISC-V architecture manual, but I think making these decisions for myself, and seeing whether I agree with their conclusions, is far more valuable.

It's also just really cool!

How?

Building and taping out a processor is an extremely expensive and time consuming process. I obviously wasn't going to be spending millions on this, so needed to explore some less conventional options.

One approach is to build the processor by hand using Transistor-Transistor Logic (TTL) chips and breadboards or custom PCBs. Ultimately, I decided against this approach for Idli as it felt a bit too restrictive on the kinds of microarchitectures that I'd be able to work with. Having said that, I very much intend to come back to TTL in the future with a simpler design as it looks like an extremely satisfying process.

Using an FPGA is another approach which is frequently taken by hobbyists designing their own hardware. One particularly impressive example of this is MRISC32, a custom processor by Marcus Geelnard, which even has its own GCC and DOOM port. However, the microarchitecural decisions you make when designing for an FPGA vs ASIC are quite different, and I wanted to focus on the latter, so decided against targeting an FPGA.

I eventually landed upon Tiny Tapeout as my best option. This is a shuttle program where different groups or individuals purchase tiles of space on a silicon wafer in which to build their designs, which can then be individually enabled at runtime. This brings down the cost of taping out significantly, as you're sharing part of the expense across all the different designers that purchased one or more tiles. There's also a whole host of extremely impressive projects to browse though that have been taped out in previous shuttle runs.

Another benefit of Tiny Tapeout is that your design has certain external restrictions placed upon it, most notably the area available for your design and the number of input and output pins it can access. As someone who frequently makes grand plans that I have no hope of actually completing, these limitations help me to keep the scope from ballooning beyond what I have the time to realistically implement. Working within constraints is also a great source of creativity and a fun way to explore new and less conventional ideas that may not make sense elsewhere.

I'm very fortunate in that I work in this area professionally, so I'm already familiar with the tools of the trade and have access to many coworkers who are far more experienced than me off whom I can bounce some ideas. This has been invaluable as a source of knowledge and inspiration, but for those who don't have the same opportunity I'd highly recommend reading through the threads on the comp.arch usenet group (I do this via Thunderbird), as many of the regulars have a huge amount of experience in this area.

Why the Name?

As anyone familiar with software or hardware development knows, the hardest part of any project is coming up with a name for whatever it is you're making. After struggling with this for a while, I attempted to explain it to my (extremely patient) girlfriend, who suggested the name Idli.

Idli is a tasty South Indian food that also has the benefit of looking kind of like a fleet of little flying saucers. As my processor needed to be simple enough to be achievable in my spare time and fit into as few tiles as possible for Tiny Tapeout, she thought Idli was a good fit as the food itself is "small and cute." You just can't argue with that, and thus Idli was born.

Onwards

With the hardest part of the project out of the way, the next step was to actually come up with a viable architecture given the restrictions on the design space. So without further ado, let's dig in (Coming soon!).