Improve incremental repair running times so that megaboom can be done in 24 hours

[oharboe]

Description

repair_timing breaks the 24 hour budget for megaboom, so repair_timing has been disabled.

Note that repair_timing is not the biggest problem in megaboom(the clock period is ca. 3000ps now and I believe repair timing is a small fraction of that...), so this is a forward looking feature request to when macro placement has been addressed.

Untar https://drive.google.com/file/d/14-UYL5iUD1GWlL10sYCOPIB0jOpVYDzd/view?usp=sharing

./run-me-BoomTile-asap7-base.sh

[deleted]
[INFO GRT-0018] Total wirelength: 40146727 um
[INFO GRT-0014] Routed nets: 1976482
Perform buffer insertion...
[INFO RSZ-0058] Using max wire length 162um.
[after hours, still running]
[deleted]
repair_timing -verbose -repair_tns 0
[INFO RSZ-0094] Found 189600 endpoints with setup violations.
[INFO RSZ-0099] Repairing 1 out of 189600 (0.00%) violating endpoints...
   Iter   | Removed | Resized | Inserted | Cloned |  Pin  |    WNS   |   TNS      |  Viol  | Worst
          | Buffers |  Gates  | Buffers  |  Gates | Swaps |          |            | Endpts | Endpt
---------------------------------------------------------------------------------------------------
        0 |       0 |       0 |        0 |      0 |     0 | -4099.470 | -410877536.0 | 189600 | core/iregister_read/exe_reg_rs1_data_0\[1\]$_DFF_P_/D
[deleted]
[28\]$_DFFE_PP_/D
     185* |       5 |      22 |       39 |     15 |    38 | -3812.590 | -359985248.0 | 189577 | lsu/ldq_31_bits_uop_debug_inst\[28\]$_DFFE_PP_/D
[still running after 10 hours or so, stopped]

Suggested Solution

Make repair_timing faster

Additional Context

No response

[oharboe]

after 8 hours or so, the stack trace is the below...

Hmm.... throw is used to abandon things when searching for a solution, could this be done without exceptions to improve performance?

__cxa_throw (@__cxa_throw:3)
sta::DmpPi::evalDmpEqns() (.cold) (@sta::DmpPi::evalDmpEqns() (.cold):20)
sta::DmpAlg::findDriverParams(double) (@sta::DmpAlg::findDriverParams(double):543)
sta::DmpPi::gateDelaySlew(double&, double&) (@sta::DmpPi::gateDelaySlew(double&, double&):21)
sta::DmpCeffDelayCalc::gateDelay(sta::Pin const*, sta::TimingArc const*, float const&, float, sta::Parasitic const*, std::map<sta::Pin const*, unsigned long, sta::PinIdLess, std::allocator<std::pair<sta::Pin const* const, unsigned long>>> const&, sta::DcalcAnalysisPt const*) (@sta::DmpCeffDelayCalc::gateDelay(sta::Pin const*, sta::TimingArc const*, float const&, float, sta::Parasitic const*, std::map<sta::Pin const*, unsigned long, sta::PinIdLess, std::allocator<std::pair<sta::Pin const* const, unsigned long>>> const&, sta::DcalcAnalysisPt const*):92)
sta::GraphDelayCalc::findDriverArcDelays(sta::Vertex*, sta::MultiDrvrNet const*, sta::Edge*, sta::TimingArc const*, std::map<sta::Pin const*, unsigned long, sta::PinIdLess, std::allocator<std::pair<sta::Pin const* const, unsigned long>>>&, sta::DcalcAnalysisPt const*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc::findDriverArcDelays(sta::Vertex*, sta::MultiDrvrNet const*, sta::Edge*, sta::TimingArc const*, std::map<sta::Pin const*, unsigned long, sta::PinIdLess, std::allocator<std::pair<sta::Pin const* const, unsigned long>>>&, sta::DcalcAnalysisPt const*, sta::ArcDelayCalc*):111)
sta::GraphDelayCalc::findDriverEdgeDelays(sta::Vertex*, sta::MultiDrvrNet const*, sta::Edge*, sta::ArcDelayCalc*, std::array<bool, 2ul>&) (@sta::GraphDelayCalc::findDriverEdgeDelays(sta::Vertex*, sta::MultiDrvrNet const*, sta::Edge*, sta::ArcDelayCalc*, std::array<bool, 2ul>&):71)
sta::GraphDelayCalc::findDriverDelays1(sta::Vertex*, sta::MultiDrvrNet*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc::findDriverDelays1(sta::Vertex*, sta::MultiDrvrNet*, sta::ArcDelayCalc*):108)
sta::GraphDelayCalc::findDriverDelays(sta::Vertex*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc::findDriverDelays(sta::Vertex*, sta::ArcDelayCalc*):31)
sta::FindVertexDelays::visit(sta::Vertex*) (@sta::FindVertexDelays::visit(sta::Vertex*):72)
sta::BfsIterator::visit(int, sta::VertexVisitor*) (@sta::BfsIterator::visit(int, sta::VertexVisitor*):72)
sta::GraphDelayCalc::findDelays(int) (@sta::GraphDelayCalc::findDelays(int):48)
sta::Sta::searchPreamble() (@sta::Sta::searchPreamble():25)
sta::Sta::findRequireds() (@sta::Sta::findRequireds():7)
rsz::RepairSetup::repairSetupLastGasp(rsz::OptoParams const&, int&) (@rsz::RepairSetup::repairSetupLastGasp(rsz::OptoParams const&, int&):437)
rsz::RepairSetup::repairSetup(float, double, int, bool, bool, bool, bool, bool) (@rsz::RepairSetup::repairSetup(float, double, int, bool, bool, bool, bool, bool):739)
_wrap_repair_setup (@_wrap_repair_setup:124)
TclNRRunCallbacks (@TclNRRunCallbacks:38)
___lldb_unnamed_symbol1507 (@___lldb_unnamed_symbol1507:348)
Tcl_EvalEx (@Tcl_EvalEx:11)

[oharboe]

@jeffng-or @precisionmoon @maliberty In addition to improving performance, can we add some logic to abandon futile repair timing automatically?

WNS is -3812.590ps for 3000ps clock period. Isn't repair_timing an exercise in futility at that point?

[maliberty]

I continues as long as there is some progress, not based on the clock period.