The-OpenROAD-Project
recover_power is very slow
Description
Tar made with make DESIGN_CONFIG=designs/asap7/jpeg_lvt/config.mk global_route_issue
untar https://drive.google.com/file/d/1Aax8fTJl9KyA0rl7YNv8mwu5yG4kaBeo/view?usp=sharing
Run:
./run-me-jpeg_lvt-asap7-base.sh
$ ./run-me-jpeg_lvt-asap7-base.sh
OpenROAD v2.0-13348-gd423155d6
[deleted]
[quickly, a few minutes, gets to here and then it is stuck for ca. 1-2 hours]
Downsizing/switching to higher Vt for non critical gates for power recovery
Percent of paths optimized 100
tns 0.00
wns 0.00
Group Internal Switching Leakage Total
Power Power Power Power (Watts)
----------------------------------------------------------------
Sequential 1.34e-02 2.66e-03 6.57e-06 1.61e-02 20.9%
Combinational 2.25e-02 3.23e-02 1.04e-05 5.48e-02 71.2%
Clock 3.64e-03 2.43e-03 1.39e-07 6.07e-03 7.9%
Macro 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.0%
Pad 0.00e+00 0.00e+00 0.00e+00 0.00e+00 0.0%
----------------------------------------------------------------
Total 3.96e-02 3.74e-02 1.71e-05 7.70e-02 100.0%
51.4% 48.6% 0.0%
Compared to the rest of the flow, global route is surprisingly slow:
Log Elapsed seconds Peak Memory/KB
1_1_yosys 243 971412
2_1_floorplan 27 510688
2_2_floorplan_io 4 363812
2_3_floorplan_tdms 4 362360
2_4_floorplan_macro 4 367364
2_5_floorplan_tapcell 4 325804
2_6_floorplan_pdn 6 381020
3_1_place_gp_skip_io 38 461672
3_2_place_iop 4 372996
3_3_place_gp 613 1048224
3_4_place_resized 94 602152
3_5_place_dp 78 657092
4_1_cts 152 747132
5_1_grt 6137 1298604
5_2_fillcell 5 494576
5_3_route 543 11470100
6_1_merge 15 815860
6_report 198 2751824
Total 8169 11470100
Suggested Solution
Hopefully this is just a good example of a pathological slowdown and making it faster should be possible.
Additional Context
No response
94% of the time is spent in: https://github.com/The-OpenROAD-Project/OpenROAD/blob/441581bc5af322bc122e6a018d8d1bbdab0649e5/src/rsz/src/RecoverPower.cc#L81-L226
It's doing ~4500 of iterations of this: https://github.com/The-OpenROAD-Project/OpenROAD/blob/441581bc5af322bc122e6a018d8d1bbdab0649e5/src/rsz/src/RecoverPower.cc#L126
Each iteration is about 1s, so it adds up.
There are three parameters that determine the iteration count. One is customizable via Tcl, it's called RECOVER_POWER:
https://github.com/The-OpenROAD-Project/OpenROAD/blob/441581bc5af322bc122e6a018d8d1bbdab0649e5/src/rsz/src/RecoverPower.cc#L112
This parameter is set to 0 by default for most designs in flow-scripts, like Ibex or BlackParrot, so this step is skipped entirely there. For jpeg_lvt, it's set to 100%.
(sorry if this is obvious to you)
The other two are setup_slack_margin_ and setup_slack_max_margin_:
https://github.com/The-OpenROAD-Project/OpenROAD/blob/441581bc5af322bc122e6a018d8d1bbdab0649e5/src/rsz/src/RecoverPower.cc#L93-L95
They're defined here: https://github.com/The-OpenROAD-Project/OpenROAD/blob/441581bc5af322bc122e6a018d8d1bbdab0649e5/src/rsz/src/RecoverPower.hh#L124-L128
They are constants, so they cannot be tweaked by the user. They were chosen in this commit: https://github.com/The-OpenROAD-Project/OpenROAD/commit/2611d81ac68366eea38e2d88937e14e7a4fc4adf, not sure if a rationale was provided.
Anyway, it doesn't seem like a pathological case, unless these constants are incorrect. The only options I see are to either tweak them or the RECOVER_POWER param, or speed up sta::Search::findRequireds() which takes up 88% of the run time (called by rsz::RecoverPower::recoverPower).
RECOVER_POWER is an opt-in flow variable. For prototyping I don't think it is helpful unless you are trying to make a study of power. We will address the performance but I'm not sure it should matter to you.
@oharboe Can you try this again with the current master? Is the performance acceptable now?
@kbieganski We don't actually use recover_power currently, but thanks for fixing this!