Possibility of a loadable plugin architecture?

[mattyoung101]

Hi everyone!

I'm wondering about your thoughts on the possibility of adding a dynamically-loaded plugin architecture to OpenROAD. Most of my prior work comes from the land of Yosys, where we have the ability to create shared-objects that act as Yosys plugins, and load these at runtime using the plugin -i command.

Is this something that there would be any interest, or tolerance, to having in OpenROAD? At the moment, my understanding is that all the modules (placer, router, etc) with the exception of OpenSTA are statically linked into the openroad executable.

I ask because I am hoping to start a PhD next year on FOSS EDA, and as part of this work, I'm interested in doing this work as a feature to OpenROAD. The advantages for me are that I can write a plugin which adds my niche feature (in this case, radiation tolerant PnR) and I can maintain it separately, without having to rebase onto upstream often. There is also the possibility that commercial users could add plugins as features, while still contributing to the core OpenROAD upstream (I'm not sure if this is desirable in this project, but it is a possibility to discuss).

Thanks in advance for your feedback :)

[maliberty]

The yosys IR is rather stable so plugins have a good target. The internal APIs of OR evolve a lot more so I'm not sure if you would avoid rebasing often. I'm open to the idea but I don't think it as simple as just enabling loading of a .so.

[mattyoung101]

Ah thanks, that makes sense yeah. Say for example if I wanted to implement another placer, would that mainly interact with the OpenDB API? And how stable is that? Alternatively, if I wanted to slightly tweak the objective function of RePlAce as it's currently implemented now, roughly how stable is that API?

Otherwise, yes, I see what you mean, and I'd probably manage this through a fork or patch set.

[maliberty]

Will you placer consider timing or routing congestion as the current placer does? If so your set of dependent APIs will expand. ODB is getting some additions for chiplet systems but probably would be stable enough for your use case. sta is relatively stable but when multi-mode is complete there will be some churn. So long as the expectation are set appropriately I don't mind.

Tweaking the replace objective function is possible but not well encapsulated. You would need to also compute the derivative of your tweaks for the nestrov algorithm. Do you have more details on what you plan to do? Is "radiation tolerant" similar to "radiation hardening"? There is a niche market that cares about that (eg space).

[mattyoung101]

I would hypothetically like to keep any future placer (or router) close to the upstream behaviour, so yeah it would probably need to consider timing and congestion. Do you roughly know whenabouts the multi-mode work would be complete (sorry, I'm not up to date on the OpenROAD roadmap). I imagine my work would be taking place in ~9-12 months.

Thanks for the info about the objective function modifications, that's really interesting. I don't mean to derail the original topic too much, but are numerical derivatives supported? Even if I need to bring my own library, e.g. autodiff or similar.

Unfortunately, I don't really have too much info yet on what I plan to do as I haven't completed my literature review yet (in fact, my PhD application is still pending). But yes, radiation tolerant I used here (probably incorrectly) as a synonym for radiation-hardened. I did my thesis on this is the past, so that's sort of my niche area now. Generally, I imagine, I'd be implementing some sort of radiation transport model (which may be hard to differentiate..) and modifying the behaviour of the placer, or router, to accommodate findings from this model.

[maliberty]

MM should happen in your timeframe.

The current objective has an analytic derivative coded up so we don't use autodiff or similar.