![[object Object]](/lib_CUsguFEVafmoKCKW/ns6hm1s6vu8ctynd.png?w=334)
Background
With the release of the world's first open-source fully-manufacturable PDK in 2019 by Google and Skywater, we at Efabless endeavored to provide an RTL-to-GDSII flow compatible with that PDK, built entirely on free and open-source utilities, so community members may for the first time design ASICs entirely only using open-source software.
With nearly 1000 stars on GitHub and 1,617 unique cloners in the last month alone, as well as its positioning for use with the Google OpenMPW shuttle, OpenLane has become the world's most popular open-source RTL-to-GDS-II flow. We bore witness to the creation of a vibrant ecosystem of open-source silicon designs and a community of around 6,000 designers exploring the new frontier of open-source ASIC design, with interesting projects in both the digital and analog spaces.
However, as you probably know, OpenLane is not perfect. Far from it. Evolving from a Makefile and then a shell-based backbone without defined interfaces, OpenLane's architecture was not easily scalable and/or extensible, frequently hampering the adoption of more features and utilities in a robust manner. Configuration variables quickly became sprawling and inscrutable, with many variables' documentation frequently getting out of date (due to a lack of coupling of documentation and code.) To top it all off, OpenLane and its many dependencies continue to be cumbersome to install.
When I took over as maintainer of OpenLane in 2020, many of these problems were immediately apparent and then addressed or mitigated- Volare, for example, was written in early 2022 to help with the exceedingly long and somewhat unstable PDK build process, but as time went on, the limitations of OpenLane's ad-hoc design were starting to hamper our adoption of new features. Many bugs were introduced due to: a lack of a rigorous interface for the various components of OpenLane, innumerable instances of code and functionality duplication, and the use of Tcl, a shell-first language with a limited (but passionate) community, as a backbone for the flow.
As our designs and projects progressively became more complex, so did our requirements, and it quickly became apparent to all of us that as it stood, OpenLane was not meeting those requirements, and neither did any of its alternatives. While alternatives to OpenLane were more flexible and offered a lot to advanced users, ultimately, they were typically more time-consuming to set up and install- lacking bundled tools and PDK management for example, but more importantly they lacked compatibility with the existing corpus of designs by both Efabless and the community.
We have thus decided to tackle rebuilding OpenLane from the ground up, with the intent of making OpenLane more robust, more extensible, and easier to deploy. We have been hard at work on this for almost a year now, and so, we are elated to finally present the next-generation of OpenLane- version 2.0.0.
About OpenLane 2
OpenLane 2 is a complete re-imagining of OpenLane not just as a simple, somewhat customizable flow, but rather as an infrastructure that can support innumerable flows. Written in Python with strict type-checking, automatically-generated documentation and extremely well-defined interfaces, OpenLane 2 formalizes the concepts of Steps as an execution unit achieving a certain functionality in ASIC design, and the concept of a Flow- an aggregation of these steps to achieve the implementation of a complex piece of silicon.
In addition to a plugin system that allows the creation of custom Steps and Flows, OpenLane 2 also comes with a number of included Steps and Flows, the default Flow being Classic- which is essentially the recreation of the OpenLane 1 flow with new enhancements, and more importantly, 99% compatibility with existing designs and config files. No, really. Whether your config is in JSON or in Tcl, OpenLane 2 will load your configuration file and in the overwhelming majority of cases harden your design without missing a beat.
To help with deployment and delivery with OpenLane to the end-user, we've decided to unify our build processes to rely on Nix. Nix is a build-system and package manager with an intense focus on reproducibility, allowing builds and development environments to be specified in a declarative manner using a functional programming language. We use Nix to build the various open-source utilities on which we depend, including but not limited to: Yosys, OpenROAD, Magic, KLayout and Netgen, cache these reproducible builds using a Nix-derived utility named Cachix and distributed them either using Docker-compatible containers or in native shells on Linux and macOS.
Why Migrate to OpenLane 2?
In short, the Classic OpenLane 2 flow is far more robust than the OpenLane 1 flow while still being backwards-compatible. Any config.json or config.tcl file you have on hand, with very limited exceptions, still works as you would expect, but with a lot less bugs- and with some conveniences:
- Full configuration validation: if you have a typo, it will be caught, and if you accidentally provide a string to a number, it will be caught.
- Full variable documentation: Our underlying automation means that you won't find an undocumented or mis-documented variable again.
- More graceful failures: if the design fails mid-flow, because of a more strict separation of concerns, you still have access to metrics and reports from all previous steps.
- The ability to use command-line flow control options such as --from, --to, --skip and --only, with the ability to resume from a snapshot of your design at a certain part of the flow, without worrying about surprises related to state variables missing.
Furthermore, the flow has many additional features, including for example full flexibility in static timing analysis, allowing you to pick the corners on which post-PNR STA is performed.
If you're a more savvy user, a whole new world of possibilities await with OpenLane 2, as it is not just a mildly configurable flow like OpenLane, but a complete, well-documented infrastructure for implementing hardware flows. OpenLane 2 can implement hardware flows for designs including ASIC and FPGA by relying on basic Python object-oriented programming principles, and this naturally allows you to:
In fact, OpenLane 2 is already in use by ambitious projects such as https://tinytapeout.com/, where it is used to harden various macros for the fourth TinyTapeout (chiefly the multiplexer) leveraging custom flows and custom steps to tape-out a complex chip for Efabless's ChipIgnite shuttle.
What's Going to Happen to Older Versions of OpenLane?
For now, nothing.
Development on the older versions (internally, we collectively just call them OpenLane 1) will be winding down, and we will be eyeing the release of an "OpenLane 1.0.0" for the final, feature-frozen Tcl version, but the two generations of OpenLane will coexist until the new infrastructure is silicon-proven, and OpenLane 1 will remain the primary recommended method of hardening your designs for shuttles until then.
However, for research, education and if you simply find OpenLane 1 too limiting, OpenLane 2 may just be what you're looking for.
Getting Started
Before you install anything, you can check out the Google Colaboratory for OpenLane 2, completely free with a Google account at this link: https://colab.research.google.com/github/efabless/openlane2/blob/main/notebook.ipynb
You can get started with installing and using OpenLane 2 at: https://openlane2.readthedocs.io/en/latest/getting_started/index.html.
You can find the beta under the GitHub repository at https://github.com/efabless/openlane2.