search

The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.54k stars 540 forks source link

Make timing update in GUI faster and add an 'out' if it is taking too long #5931

Open oharboe opened 4 hours ago

oharboe commented 4 hours ago

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

image

GUI is stuck for a long time(minutes).

image

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

gadfort commented 4 hours ago

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?
QuantamHD commented 3 hours ago

@gadfort Since this is a read only op maybe we could make the call async?

gadfort commented 3 hours ago

@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