GSoC `21: Preparing the BlackParrot for Tapeout using the Open-Source Google-Skywater 130nm PDK
I’m Lakshmi, I’m a student of hardware design and machine learning pursuing my Master’s at Georgia Tech. I am humbled to have been able to tapeout a design in the first ever Google-Efabless MPW shuttle and also in it’s recent 2021 iteration. Though my interest is in hardware design and machine learning, I’m open to anything that has the potential to create a significant impact. Is a technology innovative and challenging, and of greater significance to the world? I’m in.
The Inspiration 🚀
It all took shape with my first communication with Prof. Taylor from the University of Washington. I had been looking out for opportunities in my domain and when he suggested this project idea, to prepare the BlackParrot processor for tapeout on the Skywater 130nm technology node, I was excited. Ambitious indeed it is but a challenge worth taking up.
A technology node can be understood as a technology that allows design of integrated circuits at a certain minimum possible level of detail. For example, the smallest feature that can be implemented using the Skywater 130nm node would be of 130 nanometers. The information that enables us to design integrated circuits for such a technology node is a package called the PDK or the Process Design Kit. If we look at the VLSI (Very Large Scale Integration) industry, we can see that most PDKs that enable the manufacture of ICs, are closed-source and not available to the public. In this context, the Google-Skywater collaboration created a revolution by pushing out the open-source Skywater 130nm PDK.
The BlackParrot is a tiny, open-source, reliable, Linux capable processor that strives to be community driven and infrastructure agnostic. It is easy to use, integrate and modify and at the same time it’s light weight yet supports muti-core configurations with cache coherence. It is also a silicon proven design that has previously been taped-out on commercial technology nodes in 40nm and 12nm. To be able to have a processor of this capability on the Skywater 130nm node, using fully open-source tools alone is then a milestone that’s waiting to be conquered. So I sent my best proposal for the same to FOSSi to join hands with them to achieve this.
GSoC opened up windows of opportunity for me which I previously didn’t have. I was able to connect and interact with passionate professionals who are knowledgeable and experienced in the field, and the things I got to work on were quite interesting and diverse. Most important is the fact that the work I’m getting to do is something that the open-source hardware community is looking forward to, and also something that involves the use of the latest in open-source hardware design technology. It is challenging and exhilarating at the same time.
The Journey 🛩
It was quite challenging. Starting off, I got to explore about BlackParrot and a basic necessity that is needed to put a processor through an RTL to GDS flow -the memories that it needs. Any processor would have some form requirement for storage — as registers, caches and so on. To meet that we need memory in form of SRAMs. I was able to tweak an existing ‘Fake’ram generator to generate placeholders for these memories on sky130 node, and then use those to put the processor through the open-source flow OpenLane. I also explored generation of SRAMs using the OpenRAM compiler but it would required a different level of testing to verify it’s proper functionality for a real-life use-case so it was decided to stick with ‘Fake’rams and existing SRAMs available for the Skywater 130nm node.
One of the immediate realizations was that putting a processor through an RTL to GDS flow was something that was far from being quick — it would take a whole day or days depending on how large and complex the design really is. This really built up the difficulty since if any error happens during the flow, the whole process needed to be started again after figuring out whatever needed to be corrected, and this turn-around time rendered iterative troubleshooting infeasible.
The next idea was to break down this whole process into smaller bits by putting smaller designs through the flow and using this as a way to explore and troubleshoot the errors that occur. This way it was possible to speed up the process a bit as it provided more room for troubleshooting iteratively.
The next bit of boost was obtained when I found out about the ‘interactive’ mode in OpenLane. This mode basically allows you to go step by step through the flow. This allows for debugging individual steps and to repeat any step if it fails or if it doesn’t complete properly before proceeding to the next step. This enabled a lot more room for troubleshooting and fixing errors. For the process of trouble shooting I made two tiny designs — a ‘Fake’ram wrapper and an SRAM wrapper, which are basically just Verilog code that instantiates a ‘Fake’ram and SRAM respectively. The idea is these designs are small and hence they go through the flow quickly and are much easier to troubleshoot. These two designs successfully completed the RTL to GDS flow without DRC or LVS issues. I also attempted with larger designs, one of which was the BSG manycore tile design. It takes more time than the smaller designs and could reach till the detailed routing step of the RTL to GDS flow.
The main blockage for the actual BlackParrot design was with respect to placement. It would fail at the detailed placement step without much information. To collaborate and tackle this effectively, this error was reproduced on a smaller piece of the BlackParrot — a design which has it’s front-end alone. This goes through the flow much faster and it is hoped to use this to collaboratively figure out the issue so that it can be taken forward.
The designs used for trouble shooting the flow could be helpful for someone else who is trying to troubleshoot other designs, so I put them all together into an automated test suite that anyone can pull and easily run to test out flows and to troubleshoot their designs.
The journey is still on to take it further and achieve the original goal of preparing the BlackParrot.
A great big thanks to my mentors Prof. Taylor and Dan Petrisko, whose unfailing attention and support has helped me immensely along the way. The opportunity gave me a deep exposure into how things work at the bleeding edge of open-source RTL to GDS automation technology. When I was looking out for opportunities, I could find very few organisations that provides the chance to work in this domain of open-source hardware design and development. In fact, lowRISC and FOSSi were the organisations I could find that fully focuses in this domain. I wish in future years too, this opportunity is available uninterrupted for the students and young professionals who wish to explore and contribute in this domain with the open-source spirit. It would also be a need of the time as this could be a field that would become more and more prominent and relevant in the coming years.
Some links to work done