Subnetlist-level timing optimization APIs

[liangrj2014]

It seems that the current OpenROAD timing optimization APIs primarily operate at the circuit level. While it is possible to optimize subnetlists by setting certain components as "don't touch," this approach might result in inefficiencies.

I would like to suggest the potential benefit of providing subnetlist-level timing optimization APIs. The subnetlist, which is a Directed Acyclic Graph of gates, could represent a logic cone, a timing path, or even a part of a timing path. Users could specify timing constraints, such as the arrival time at the "starting" pins and the required arrival time at the "ending" pins, allowing the tool to optimize the subnetlist accordingly. This enhancement would greatly facilitate data generation for ML4EDA tasks within OpenROAD and provide more flexible methods for machine learning models to interact with the tools.

[maliberty]

Would you want to take the timing from the full context or are they boundary assertions for some different values?

[liangrj2014]

Thanks for the question! I think it would be more flexible to allow boundary assertions for different values. If a user wants to use the timing from the full context, they can set the boundary assertions accordingly. What are your thoughts on this? Thanks!

[maliberty]

How are you planning to optimize this subnetlist? Are you going to use OR's resizer or something else? I'm wondering whether it is better to just build a separate design. The rmp module starts down this path with re-techmapping a subnetlist.

[liangrj2014]

Thanks for the feedback! Regarding "just build a separate design", then how to annotate back (potentially a large number of) optimized sub-netlists to the original netlist and measure overall PPA? Thanks!

[maliberty]

Like rmp you would need to cut out the old gates and stitch in the new. Doing that for a large number of cases could be a performance bottleneck. Isn't it possible to evaluate the change in the subnetlist itself (at least to first order)?