EU DECIDE Project

[gtkiku]

Hi, I'm a new PhD student at Tampere University, taking part in the DECIDE EU project with the task of improving OSS EDA tools. Thought I'd introduce myself and discuss how I might best be of use to OpenROAD. I see there's a single "good first issue" label open at the moment, I can maybe have a go at some of the points in its list to get to grips with the codebase. If there are other good tasks to get to know the code, I'd be happy to hear of them.

For slightly-longer-term plans, I found some larger aspects I might like to work on, I'd be curious if they seem reasonable. Publication value is unfortunately kind of a factor in the decision making here, but anyway:

1. The research group I'm in would be particularly interested in hierarchical designs, stuff like GPGPUs and highly parallel accelerators more generally. I understand there's at least some support for hierarchical design under active development, but apperently not recommended for production. Is there some info on what the status here is and are there aspects that could be improved?

2. Detailed routing apparently takes up a significant chunk of time, as supported by existing publications and some internal designs I ran through OpenROAD. GPUs can potentially be used to improve the performance, would that maybe be something of interest? I found some kind-of-relevant previous discussion about it in Scaling the detailed router to handle circuits with 50 million cells #3974, but it's unclear to me if it lead to anything.
   2.5, Memory usage seems to also be a limiting factor in how large of a design can currently be processed. Not sure what approach might work here, but could be useful.

[maliberty]

Thanks for the interest. For GPUs we are focusing on using Kokkos as a compatibility layer so that an algorithm can run on a GPU if available but a CPU if not. Not everyone has a GPU. You can see some such work in src/gpl.

There is some support for bottom up hierarchical design (lef & liberty abstract writing). You can see examples of this in ORFS. Top-down partitioning tends to be manual and more automation could be an area for development. src/par has a hypergraph partitioner.

Memory and runtime improvements are welcome.