The-OpenROAD-Project
Make timing update in GUI faster and add an 'out' if it is taking too long
Description
from https://github.com/The-OpenROAD-Project/megaboom make gui_cts
untar https://drive.google.com/file/d/1QdyKqQWO6BHi1qziTkemKxpobmCkELbp/view?usp=sharing
./run-me-BoomTile-asap7-base.sh
set 1000 paths(it goes up to 9999), click update
GUI is stuck for a long time(minutes).
Suggested Solution
This PR is "boarding up the broken window": https://github.com/The-OpenROAD-Project/OpenROAD/pull/5925
A better solution would be to make it "tolerably fast" for all designs that can be reasonably loaded in OpenROAD or add a progress requester to load completed paths. The GUI goes all the way to 9999 paths, which is OK on small designs, but 30 minutes(?) on this design, if it scales roughly linearly.
Additional Context
No response
Doing a quick profile on this: It took 1250s to load 1000 paths (with threading it was around 390s). Nearly all the time was consumed in opensta, with a few seconds in the GUI preparing the data.
Function Stack CPU Time: Total Effective Time Spin Time Overhead Time Module Function (Full) Source File Start Address
sta::Search::findPathEnds 266.124s 0usec 0usec 0usec openroad sta::Search::findPathEnds(sta::ExceptionFrom*, sta::Vector<sta::ExceptionThru*>*, sta::ExceptionTo*, bool, sta::Corner const*, sta::MinMaxAll const*, int, int, bool, float, float, bool, sta::Set<char const*, sta::CharPtrLess>*, bool, bool, bool, bool, bool, bool) Search.cc 0x18b0aca
sta::PathGroups::makePathEnds 222.064s 0usec 0usec 0usec openroad sta::PathGroups::makePathEnds(sta::ExceptionTo*, bool, sta::Corner const*, sta::MinMaxAll const*, bool) PathGroup.cc 0x187c3ac
sta::Search::findFilteredArrivals 43.939s 0usec 0usec 0usec openroad sta::Search::findFilteredArrivals(sta::ExceptionFrom*, sta::Vector<sta::ExceptionThru*>*, sta::ExceptionTo*, bool, bool) Search.cc 0x18b0d1e
sta::Search::ensureDownstreamClkPins 0.120s 0usec 0usec 0usec openroad sta::Search::ensureDownstreamClkPins(void) Search.cc 0x18bf36a
sta::Sta::searchPreamble 67.199s 0usec 0usec 0usec openroad sta::Sta::searchPreamble(void) Sta.cc 0x18da9d0```
the 67 seconds in the preamble is unavoidable, the remainder will be a function of the amount of data you are requesting.
Maybe it would make sense to provide a popup warning when then timing path number is large to indicate that this may take a while?
@gadfort Since this is a read only op maybe we could make the call async?
@QuantamHD it's possible, but that opens the possibility of opensta getting called in different places at the same time. So that requires some real consideration for thread safety
Async is too much of a headache and won't really solve the problem (you would have to enforce that you can't do anything timing or db modification related). Discussed and rejected repeatedly.
Getting sta to allow an cancel-in-progress option would be the best. I also think it will be hard to get such an enhancement. There are a number of such places it would be useful beyond sta as well (eg cancel routing).