Final submission for Google Summer of Code '22 in OpenFASoC at @chipsalliance 🤖
For this last Summer and the month of October, I've been working on an open silicon project in the Google Summer of Code program as part of CHIPS Alliance, an umbrella organization hosted by The Linux Foundation. The project is OpenFASoC, conducted by researchers at the University of Michigan. With this text, I would like to share what I've contributed to, and how the experience has been in this journey.
OpenFASoC, an acronym for "Fully Open-Source Autonomous SoC Synthesis using Customizable Cell-Based Synthesizable Analog Circuits", is a somewhat recent piece of software that aims to, given user specifications, automatically generate physical circuit blocks that can be later used in SoCs. The project scope is mainly focused on analog and mixed-signal designs. Currently, only six designs are at work, with more to come in the future.
I've worked mainly with one of the designs, a small subthreshold temperature sensor - or, in fact, the module that builds it: the temperature sensor generator (temp-sense-gen). My initial proposal was to create a Design Space Exploration (DSE) infrastructure to optimize this generator and automatically choose the best configuration for its internal generator parameters, such as the circuit's physical design generation variables, to keep them as default regardless of user specs. However, due to the complexity of the domain - I'm an EE student at CentraleSupélec, but still undergraduate - me and my mentor, prof. Mehdi Saligane, chose to change the goal to rather improve the current temperature sensor design generation, and at the end propose an opening for a future DSE project.
This is how the mixed-signal temperature sensor block looks like. It's cool, isn't it?
The team working on OpenFASoC consists of researchers from UMich, professionals of the industry committed to open source software and a few students from different parts of the world, with my mentor being the lead. Communication was done by Slack and meetings were organized twice a week, with meeting hours being a minor inconvenience in such an international team. In fact, this characteristic of the project was one of the most enriching to me, as I could obtain an experience of working with people from different backgrounds, that communicate in different ways, and in a remote setting which is becoming more and more common.
This project was set as of long duration (~300 hours), with an agreed extended deadline of October 24th.
Regarding development, in this project I mainly used:
- OpenROAD
- OpenROAD Flow Scripts
To some extent, these tools were also used:
- KLayout
- Netgen
- Magic
In terms of programming languages, it mainly required:
- Python: for reading and writing scripts
- Tcl: for writing scripts to control the physical design generation flow
Other languages, used less frequently, were:
- C++: to read and debug OpenROAD code
- Verilog: to understand how the circuit description files are modified by the generator
There was also exposure to some types of files common in electronics physical design software, mainly:
- SPICE files: to debug simulation and LVS files
- DEF/LEF files: for describing and debugging the physical layout
We can divide the work done in three timeframes:
Being a fairly new repository (it was created in March 2021), OpenFASoC still doesn't have some of the features that mature projects do, which posed added difficulties during GSoC. Here are some of them:
- Lack of documentation
- Dependencies are very unstable and update often
- Project structure can change frequently
- The tool is not yet packaged
- No release schedule
- Installation is all done manually
Those were major challenges at the start of the program, and while some have been addressed during GSoC (such as added installation options and documentation), they remain as difficulties to new contributors that will definitely get sorted as the project grows.
Because of this, the first weeks were dedicated to familiarizing with the tools that the project used and tackling small issues. Main points were:
- Ease the installation of dependencies by using Conda packages
- Experiments with the working generators
- Study of the integrated circuit design flow
The month of August used to tackle a major dependency problem for the temperature sensor generator: the update of its flow scripts to the latest version of the OpenROAD tool. OpenROAD is an open source software that allows for the generation of physical circuit layouts from Verilog descriptions, so it is crucial to most generators in OpenFASoC. When updating it, I tried to change the OpenFASoC flow slightly to keep it as close to OpenROAD Flow Scripts as possible, to make it easy to update in the future since ours was a fork of it. This change would make it possible to later add punctual improvements to the generator in the third phase.
As a consequence, main points were:
- Study of the OpenROAD RTL-to-GDS tool
- Update the temperature sensor generator to use the latest version of OpenROAD (pull request #82)
- Organize generated artifacts
- Restructure docs and document the temperature sensor generator flow (pull request #100)
During the last phase, I worked on improving the automatic generation of a placement and routing of cells that connect to multiple voltage sources.
Basically, OpenFASoC's temperature sensor design has two voltage domains: VDD/GND and VIN/GND, so most circuit components (which we call instances) has one or the other as a supply. Some components (the so-called header cells), however, are responsible for generating VIN from VDD, so they must connect to both voltage domains. The singularity of this case caused the generated route to be less than ideal - it was too thin and didn't have adequate connection points, which could lead to a voltage drop in the physical implementation that deteriorates the sensor output - or to not get generated at all!
Therefore, main points were:
- Study of DEF/LEF file structure
- Procedure for custom placement of header cells
- Update power delivery network layout (pull request #111)
- Change header cells pins to higher metal layers and add nondefault rule to their route to VIN
- Implement option for making multiple connections in the VIN route to the voltage domain ring (pull request #113)
Since the proposal that got accepted to participate in GSoC was about Design Space Exploration, I figured it would be nice to create something for OpenFASoC that could futurely purpose as motivation for a DSE feature.
The original idea was to leverage the Google Cloud Platform (GCP) computing power to leave a DSE job running in the cloud, since physical circuit simulations can take hours. Also, during this GSoC, the concept of creating example Jupyter notebooks to illustrate open silicon flows rose in the community - in OpenFASoC, for example, a notebook showcasing the temperature sensor generator was created by one of the team members.
So, during the last week of the program, I chose to unite both concepts and write a Jupyter notebook to showcase DSE with the temperature sensor generator that could also be added as an example in the OpenFASoC documentation! The main point was, then:
- Experiments with Hyperparameter Tuning in GCP
- Write a Jupyter notebook, executable from Google Colab, running a DSE job in the cloud to optimize the temperature sensor generator power usage (pull request #116)
During all phases, I reached out for help from other members of the team (and of other open silicon projects), which helped a lot the development.
For the temperature sensor generator, the idea is to further improve the design, for example by minimizing chip area. The proposal of a special router to the OpenROAD team to address situations like encountered with the VIN route was also discussed. For OpenFASoC, on the other hand, work remains to be done in other generators, or new circuit designs can be proposed.
Eventually, the tool could also be packaged and converted to a command line tool: instead of cding into the repo and running make, it could be made to run in the terminal just by calling openfasoc generate, for example.
- Growing projects are hard to get into
- Dependency management is difficult
- There's a lot of very specific cases to learn in microelectronics
- Commercial physical design tools are expensive
- Communication is key
- Submit issues to not forget them, and to begin discussions
- Don't reach for help without doing your own research
- Reflect to be clear when explaining an issue, otherwise it will just confuse who you're talking with
- Know how to adapt your communication style with people from different backgrounds than mine
- Improved organization and work in remote
- Tcl, Physical Design, some Docker and GCP, ... !
Being a part of Google Summer of Code '22 was a major experience in my student life, and I can only thank everyone involved! It allowed me to get a bit more into a field I'm interested in, microelectronics, and to gain experience programming in a large project, but also to work with people from all over the world (the US, India, Morocco, Ethiopia, Rwanda, Japan, ...). In July, I also attended a conference on open silicon, the FSiC2022, which out of luck happened in Paris (the city I'm living in) and allowed me to meet my mentor in person!
To finish, here are some numbers:
- Pull requests merged: 7
- Issues opened: 12
- Issues closed: 9
- Commits: 27
- Lines of code added: +612655*
- Lines of code removed: -358035*
- Optimized power consumption of the temperature sensor: 436 uW
*This enormous number of lines of code is mainly due to the temperature sensor OpenROAD fork update! :)