OpenROAD: Foundations and Realization of Open, Accessible Design

[For readability, moderator comments have been removed, as well as minor questions for better understanding.]

Thank you for the introduction and the invitation to OSDA 2023. As you can see from the logos, it's definitely not me. It's a whole bunch of very dedicated and talented people who have worked for five years on OpenROAD. So I'm excited to see so many colleagues who are interested and who share the vision of open-source EDA. And this is a talk about OSDA perspectives from the OpenROAD project.

So OpenROAD aims for no human in the loop, tape out clean GDS, so RTL to GDS in FinFET nodes in 24 hours. The project has over 600 tape outs in foundry, 130 nanometer to 12 nanometer. There's a growing community of contributors and supporters and OpenROAD supports education and outreach on many levels, whether through IEEE societies or the Google Skywater shuttles or contests and STEM workshops, et cetera. It's also the basis for research in both EDA and hardware design, and it addresses needs of small R&D teams that otherwise face too many barriers to getting ideas into silicon. So several flows have also been built upon OpenROAD. And the project owes a lot to its unique partnership between academic researchers and the team of EDA veterans at Precision Innovations.

So where is OpenROAD going? Well, we work on pretty much every green box you see here, which stretches our team's resources. But I want to mention two overarching directions. The first is, what can we enable with unlimited copies running at the same time? And we've been working on cloud-optimized physical design, what we call COPILOT, and this takes us strongly into the realm of machine learning to predict doomed subtasks and so on. There's also low-hanging fruit, like black-box hyperparameter optimization or autotuning, which finds superior flow settings than our internal design experts can, and they never imagined such things even were possible. And in this vein, we've spun up as many as 30,000 cloud instances at once in a project with Intel.

The second overarching direction is to enable faster and more accurate exploration of architecture and floor plan options. Shortening the time to useful PPA feedback is very valuable these days. And so there's a new macroplacer called Hierarchical RTLMP, which understands RTL hierarchy and data flow. It delivers very human expert-like results. This is an AI accelerator in Global Foundries 12LP with 760 macros, and we think users will start to autotune this new macro placer, use it for early design space exploration, build hybrid flows with commercial tools, or other possibilities. Early design exploration also depends on partitioning that understands timing and modern constraints. So TritonPart is a very strong partitioner that is also new in OpenROAD.

But I did not come from San Diego to give a 10-minute talk about OpenROAD. It's much more important to think about, I feel, what can be the lasting outcomes from this workshop, including directions for open-source design automation as a community. So what is this cartoon? It shows the hockey stick of area and power on the y-axis versus clock period, which is increasing on the x-axis. So open-source in red is worse than closed-source in blue, which is worse than some unknown black optimal hockey stick. And the red hockey stick is basically all of us. The huge challenge, then, for all of us is shifting the red hockey stick from today to tomorrow, and the question is "HOW?". So I feel one answer to "HOW?" is what we just saw, develop better engines for key optimizations, jump in where traditional EDA vendors are only wanting to tiptoe, like cloud or data for machine learning in an open way, hooks for machine learning, and so on. But that's not it. The real challenge and the most important direction, in my opinion, is efficiency as a community. So open-source EDA has a huge number of needs, too many, and not enough people. So I want to give a few thoughts about this.

So thought number one is that bars matter a lot. Is it good enough? How relevant is it in terms of functionality, the data produced, the quality of results, and so on? Whatever the answer, is it measurably and continuously improving? Is it actively supported? And these are some aspects of good enough. And can I rely on it? Because there's student code versus professional code. There's training, documentation, user community, availability with what terms and conditions. And all of these bars questions, relevance and quality in particular, are always coming at academic and open-source EDA. So one question to think about is do we need more wood behind fewer arrows, as they say.

Thought number two is if it's infrastructure, it's a commodity. Infrastructure is not differentiating. It just needs to exist. So should highway signs be green or blue? Should stop lights be vertical or horizontal? Pick one and move on. So I'm convinced that data model, database, STA, readers and writers, PDK support, loggers, extension language support, GUI, should be like plumbing and utilities. If they work, you don't think about them, which is also a bar. So in my personal universe, METRICS2.1 or OpenDB or OpenROAD or whatever, we need elements of some road bed upon which we build a road ahead for OSDA and the open hardware ecosystem. For instance, for research on machine learning in EDA, which has to include open data and explainable models and optimization benchmarking, we don't need five road beds, but we need at least one. And actually standards, interoperability, efficiency, frameworks, they're everywhere in the history of EDA and IC design. Without them, there's just fragmentation of resources and towers of Babel, which are just bad. So it really is a matter of putting more wood behind fewer arrows.

The third thought is we shouldn't forget that good proxies are essential to the development and adoption of open-source EDA. What do I mean by this? Open-source EDA is often rejected because there is poor validation or confirmation of relevance and value. And the root cause of this, if you really think, is that something somewhere was not shareable. Not shareable implies the need for high quality, open proxies. Proxy PDKs and enablements. Proxy EDA tools that we can benchmark and record data from. Proxy test cases that are relevant, that drive design automation, and its progress into the future. So if proxies are not good enough today, it actually blocks the entire community and this community needs to invest efforts accordingly. It may be a journey, but there is a saying for that ["A journey of a thousand miles begins with a single step"].

So in conclusion, this really was an OpenROAD talk. Efficiency has always been the biggest challenge. How can we move faster and achieve more as a community? So the three thoughts were first, bars of critical mass, critical quality matter. Second, infrastructure is a commodity. It's not differentiating. So pick something and move on. And it's actually very harmful to try to build five different road beds when at the end of the day, your end goal is to have a road. Third, not shareable always ends up being a blocker. So we need to continually improve proxy PDKs, tools, and enablements. What will be the lasting outcomes of this workshop? Hopefully new friendships and synergies formed today will take us more quickly to some better tomorrow. I look forward to the discussions, you know, after we're done and during the breaks. Here is kind of the usual links slide just for the video. The third item in particular is a recent talk at an NSF workshop and thank you very much for being here today. I look forward to questions.

Q&A

1. I have my thoughts, I'm a little bit skeptic. Because I think, firstly, there is, in open-source, some kind of inefficiency needs. You obviously have some people who want to do it differently than what is the common practice. And second thing is that these discussions are not constant when we need to standardize things. But the last thing, what I mentioned you want to do is to be involved in standardization. So those are two thoughts I have in my mind.

   Sure. Excellent points. We are all, I think, self-selected to be very pioneering, free-spirited, and lone wolves, if you will. And there are a lot of single-passionate-developer open-source projects out there. It just so happens that to impact in a sustainable, stable way, a larger community of education, workforce development, training, bringing in a next generation of EDA researchers and developers, I personally believe that critical mass and critical quality matter. And that's been the feedback we've had through five years of OpenROAD. Through all the Birds-of-a-Feather workshops at DAC, what did the community want? They wanted a full flow. Then they wanted high quality software engineering. Then they wanted support. Before they would even begin to kick the tires. And so we kind of lived through those first few years of the project and learned a lot about what people actually want to see. And we're so far from being where we need to be. That's why I perhaps think a lot about critical mass, critical quality, and how can we actually, as a community, support seven place and route initiatives or something like that, when we don't have enough resources even for one, it seems. Hope that makes sense.

2. ... to be clear, I don't disagree with that problem statement. It's that I see a lot of problems to get a solution to that problem statement.

   There's a lot of fantastic work, and I feel like if we share with each other the know-how that, "Oh, there is an open-source FinFET capable detailed router out there", or, "There's another one at Chinese University of Hong Kong", or, "This is the one static timer that understands generated clocks and timing exceptions", you know, in a sort of industrial sense. And we share this and build upon each other's works, then we will move faster. It's a matter of attitude, culture, personalities, of course.

3. How about excitement?

   Excitement. I think people get excited. I mean, I feel like the OpenLane folks must be very excited. The SiliconCompiler folks must be excited. You know, there's high school students, there's classes. UC Santa Cruz Extension teaches a course based on OpenROAD in a couple of classes, and they, I think, were having a workshop two days ago on OpenROAD for ASIC design at UCSC Extension in the Valley. There is some element of virality and excitement, but if you're a glass-half-full person, it's very motivating. If you're a glass-half-empty person, it is also motivating in the sense of, "Oh, there's so much left to do and so little time", because, you know, the world moves fast. Moore's law has always been 1% every week. That's been tough to keep up with. And that's why I bemoan redundancy and waste or inefficiency in some of the ways I mentioned.

4. Thank you for the presentation. May I ask, I mean, can we... Actually, I'm most afraid of hearing this. I mean, it's not just, you know, me. Can we have a chance to be inspired by the Linux developments in the early stage? Like a carrot or a wheeling list? Can we be a structural maintainer rather than a harsh leadership?

   I think we've always had that in mind. Even the second program manager of the DARPA program that spawned so many projects in hardware and software, you know, had a vision of Blue Hat, not Red Hat. And we've always talked about the Linux of EDA, that sort of thing. Indeed, the funding agencies do support sustainability initiatives. How to take this into a freemium model or software-as-a-service model. Introductions to venture capitalists. All of those possibilities probably are viable today. On the other hand, people who work in open-source EDA for these past years, as I said, are very self-selected. I mean, they escaped from venture funded EDA startups and big EDA companies. So, you know, how to maintain the attractiveness of open-source development, the rewards that are very personal, you know, seeing young people attracted to the field, without sort of saddling them with this yet another startup, you know, life that they don't want to return to. That's been kind of a challenge. I think most people in the room who are in small companies are very self-selected to have the lifestyle of, you know, doing good near often the end of their careers. After decades doing the grind. And I think personally I see this challenge in finding sustainable futures. We talk a lot to philanthropists and I understand others do as well. But, you know, it's a few million dollars for each independent effort every year to even have six highly-skilled developers plus some grad students and, you know, contests or whatever. There's not a lot of multiples of millions of dollars per year lying around for us to harness. And I wonder how we will manage as a community to do the best we can with what we can harness. That's perhaps the challenge.