ASIC from scratch in 8 weeks

Veröffentlicht von

…or „how to create 8 unncessarily stressfull weeks“ in your life. Yes, I’m planning to tape out an ASIC in about 8 weeks time on the 21st of March 2022 using the free Google/Skywater OpenMPW-5 shuttle. And no, I’ve never done anything like that before. My Verilog experience is limited to a few hundred lines of simple Verilog code, so that makes it a teeny tiny bit harder. In the end this is a huge learning opportunity though and the chance of having my very own ASIC taped out is just too juicy to ignore.

Now the first problem I encountered actually has nothing to do with ASIC development itself. It was a lot more mundane than that: What kind of ASIC should I develop? I wanted it to be reasonably complex, so I can show it off at job interviews, without being too embarassed about its simplicity. On the other hand there’s a hard deadline. If I don’t make it, I leave empty handed. So at its core this was more of a project managment problem than an ASIC/Verilog problem. It came down to two options in the end:

Option 1: Display Controller

The first option was a MAX7221-style display controller. It should be able to interface with a 4-digit 7-segment display, control its brightness using PWM and display decimal numbers from an internal register. The control and data registers would be filled through the Caravel’s logic analyzer output pins. „Caravel“ -for those unfamiliar with the OpenMPW project- is the harness/template that provides a foundation for each OpenMPW submission. This project could be expanded with automatic up/down counters, edge-detecting counters, quadrature encoder input, a uart configuration and telemetry interface and similar other features. Pretty simple features, but probably doable even for someone like me.

Option 2: Robot Controller

Option number two would be line-following robot controller. The simplest variant would have 2 binary inputs and 2 PWM outputs. If either input loses contact with the line (i.e. when it goes low), the ASIC increases the PWM duty cycle of the corresponding output. This output drives the motor which hopefully turns the robot back towards the line. This options has a neat little advantage, that might come in handy towards the end: It suits itself to more impressive expansions such as a full blown microcontroller. Unfortunately I felt like there was some risk associated to this option: Feature creep. Even during the planning stage features kept creeping into the design.

Another big risk for both options (but #2 in particular) was design failure. Even if I have enough time to implement several optional features, I had no way to ensure that they would work in the end. My only way to validate my designs was by using simulation, since I had no FPGA available. A simple design can be tested easily, but with more complex designs testing becomes increasingly difficult.

For those reasons I chose to go with option #1. It’s easier, less impressive, but (hopefully) more reliable. Throughout the next 8 weeks you’ll be able to read regular updates on my progress.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.