[INFO GPL-0075] Routability numCall: 1 inflationIterCnt: 1 bloatIterCnt: 0

[oharboe]

So I thought my run was almost finished, it went fairly quickly for a while, but then it got stuck in "Routeability" below.

5 minutes until it got to the GPL-0075 progress message, then stuck there for at least 30 minutes.

What does this mean and what can I do about it?

The floorplan in my case looks quite reasonable and generous.

OpenROAD/src/gpl/src/routeBase.cpp

Line 557 in 580bd35

std::pair<bool, bool> RouteBase::routability()

[NesterovSolve] Iter: 370 overflow: 0.254754 HPWL: 19171375971
[NesterovSolve] Iter: 380 overflow: 0.250836 HPWL: 18915207500
[NesterovSolve] Iter: 390 overflow: 0.225598 HPWL: 18784146027
[NesterovSolve] Iter: 400 overflow: 0.201047 HPWL: 18784861983
[INFO GPL-0075] Routability numCall: 1 inflationIterCnt: 1 bloatIterCnt: 0

[oharboe]

A little bit of suspend/resume profiling using latest OpenROAD and release build...

Hmmm... curious. I don't think this is a performance problem, but there were a lot of exceptions thrown, so I had to turn off breakpoints on exceptions.

__cxa_throw (@__cxa_throw:3)

sta::DmpAlg::findDriverParams(double) (.cold) (@sta::DmpAlg::findDriverParams(double) (.cold):14)
sta::DmpPi::gateDelaySlew(double&, double&) (.cold) (@sta::DmpPi::gateDelaySlew(double&, double&) (.cold):50)
sta::DmpCeffDelayCalc::gateDelay(sta::LibertyCell const*, sta::TimingArc const*, float const&, float, sta::Parasitic const*, float, sta::Pvt const*, sta::DcalcAnalysisPt const*, float&, float&) (@sta::DmpCeffDelayCalc::gateDelay(sta::LibertyCell const*, sta::TimingArc const*, float const&, float, sta::Parasitic const*, float, sta::Pvt const*, sta::DcalcAnalysisPt const*, float&, float&):88)
sta::GraphDelayCalc1::findArcDelay(sta::LibertyCell*, sta::Pin const*, sta::Vertex*, sta::MultiDrvrNet*, sta::TimingArc*, sta::Parasitic*, float, sta::Vertex*, sta::Edge*, sta::Pvt const*, sta::DcalcAnalysisPt const*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc1::findArcDelay(sta::LibertyCell*, sta::Pin const*, sta::Vertex*, sta::MultiDrvrNet*, sta::TimingArc*, sta::Parasitic*, float, sta::Vertex*, sta::Edge*, sta::Pvt const*, sta::DcalcAnalysisPt const*, sta::ArcDelayCalc*):112)
sta::GraphDelayCalc1::findDriverEdgeDelays(sta::LibertyCell*, sta::Instance*, sta::Pin const*, sta::Vertex*, sta::MultiDrvrNet*, sta::Edge*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc1::findDriverEdgeDelays(sta::LibertyCell*, sta::Instance*, sta::Pin const*, sta::Vertex*, sta::MultiDrvrNet*, sta::Edge*, sta::ArcDelayCalc*):105)
sta::GraphDelayCalc1::findDriverDelays1(sta::Vertex*, bool, sta::MultiDrvrNet*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc1::findDriverDelays1(sta::Vertex*, bool, sta::MultiDrvrNet*, sta::ArcDelayCalc*):108)
sta::GraphDelayCalc1::findDriverDelays(sta::Vertex*, sta::ArcDelayCalc*) (@sta::GraphDelayCalc1::findDriverDelays(sta::Vertex*, sta::ArcDelayCalc*):63)
sta::FindVertexDelays::visit(sta::Vertex*) (@sta::FindVertexDelays::visit(sta::Vertex*):74)
sta::BfsIterator::visit(int, sta::VertexVisitor*) (@sta::BfsIterator::visit(int, sta::VertexVisitor*):71)
sta::GraphDelayCalc1::findDelays(int) (@sta::GraphDelayCalc1::findDelays(int):47)
sta::Sta::checkSlewLimitPreamble() (@sta::Sta::checkSlewLimitPreamble():82)
rsz::RepairDesign::repairDesign(double, double, double, int&, int&, int&, int&, int&) (@rsz::RepairDesign::repairDesign(double, double, double, int&, int&, int&, int&, int&):65)
rsz::Resizer::findResizeSlacks() (@rsz::Resizer::findResizeSlacks():24)
gpl::TimingBase::updateGNetWeights(float) (@gpl::TimingBase::updateGNetWeights(float):18)
gpl::NesterovPlace::doNesterovPlace(int) (@gpl::NesterovPlace::doNesterovPlace(int):1262)
_wrap_replace_nesterov_place_cmd (@_wrap_replace_nesterov_place_cmd:20)
TclNRRunCallbacks (@TclNRRunCallbacks:37)
___lldb_unnamed_symbol1504 (@___lldb_unnamed_symbol1504:315)
Tcl_EvalEx (@Tcl_EvalEx:9)

Ooops.... from within the debugger(attaching) to the release build, I ran into an recursive loop below and a SEGFAULT.

Curiously, this infinite stack recursion does not appear with the debug build, which makes for an interesting debug exercise...

rsz::RepairDesign::repairNetJunc(std::shared_ptr<rsz::BufferedNet>, int, int&, sta::Vector<sta::Pin const*>&) (@rsz::RepairDesign::repairNetJunc(std::shared_ptr<rsz::BufferedNet>, int, int&, sta::Vector<sta::Pin const*>&):16)
rsz::RepairDesign::repairNet(std::shared_ptr<rsz::BufferedNet>, int, int&, sta::Vector<sta::Pin const*>&) (@rsz::RepairDesign::repairNet(std::shared_ptr<rsz::BufferedNet>, int, int&, sta::Vector<sta::Pin const*>&):82)
[deleted 100s if not 1000s of these]
(@rsz::RepairDesign::repairNet(std::shared_ptr<rsz::BufferedNet>, sta::Pin const*, float, int, sta::Corner const*):29)
rsz::RepairDesign::repairNet(sta::Net*, sta::Pin const*, sta::Vertex*, bool, bool, bool, int, bool, int&, int&, int&, int&, int&) (@rsz::RepairDesign::repairNet(sta::Net*, sta::Pin const*, sta::Vertex*, bool, bool, bool, int, bool, int&, int&, int&, int&, int&):356)
rsz::RepairDesign::repairDesign(double, double, double, int&, int&, int&, int&, int&) (@rsz::RepairDesign::repairDesign(double, double, double, int&, int&, int&, int&, int&):195)
rsz::Resizer::findResizeSlacks() (@rsz::Resizer::findResizeSlacks():24)
gpl::TimingBase::updateGNetWeights(float) (@gpl::TimingBase::updateGNetWeights(float):18)
gpl::NesterovPlace::doNesterovPlace(int) (@gpl::NesterovPlace::doNesterovPlace(int):1262)
_wrap_replace_nesterov_place_cmd (@_wrap_replace_nesterov_place_cmd:20)
TclNRRunCallbacks (@TclNRRunCallbacks:37)
___lldb_unnamed_symbol1504 (@___lldb_unnamed_symbol1504:315)
Tcl_EvalEx (@Tcl_EvalEx:9)
Tcl_Eval (@Tcl_Eval:11)
sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) (@sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*):31)
ord::tclAppInit(Tcl_Interp*) (@ord::tclAppInit(Tcl_Interp*):128)
Tcl_MainEx (@Tcl_MainEx:111)
main (@main:742)
__libc_start_call_main (@__libc_start_call_main:29)
__libc_start_main_impl (@__libc_start_main@@GLIBC_2.34:43)
_start (@_start:15)

[oharboe]

Letting it run for a while, debug is MUCH slower than release, I see when I suspend in the debugger. There are 200000 nets to process in gen_brk_RSMT(), coeffADJ() is going through double loops for a total of 10000000 iterations...

grt::FastRouteCore::getEdgeCapacity(grt::FrNet*, int, int, grt::EdgeDirection) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/fastroute/src/FastRoute.cpp:592)
grt::FastRouteCore::coeffADJ(int) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/fastroute/src/RSMT.cpp:616)
grt::FastRouteCore::gen_brk_RSMT(bool, bool, bool, bool, bool) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/fastroute/src/RSMT.cpp:662)
grt::FastRouteCore::run() (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/fastroute/src/FastRoute.cpp:766)
grt::GlobalRouter::findRouting(std::vector<grt::Net*, std::allocator<grt::Net*>>&, int, int) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/GlobalRouter.cpp:397)
grt::GlobalRouter::globalRoute(bool) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/grt/src/GlobalRouter.cpp:285)
gpl::RouteBase::getGlobalRouterResult() (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/gpl/src/routeBase.cpp:378)
gpl::RouteBase::routability() (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/gpl/src/routeBase.cpp:566)
gpl::NesterovPlace::doNesterovPlace(int) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/gpl/src/nesterovPlace.cpp:699)
gpl::Replace::doNesterovPlace(int) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/gpl/src/replace.cpp:343)
replace_nesterov_place_cmd() (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/build/src/gpl/CMakeFiles/gpl.dir/replaceTCL_wrap.cxx:1740)
::_wrap_replace_nesterov_place_cmd(ClientData, Tcl_Interp *, int, Tcl_Obj *const *) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/build/src/gpl/CMakeFiles/gpl.dir/replaceTCL_wrap.cxx:2190)
TclNRRunCallbacks (@TclNRRunCallbacks:37)
___lldb_unnamed_symbol1504 (@___lldb_unnamed_symbol1504:315)
Tcl_EvalEx (@Tcl_EvalEx:9)
Tcl_Eval (@Tcl_Eval:11)
sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/sta/app/StaMain.cc:95)
::tclAppInit(int &, char **, const char *, Tcl_Interp *) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/Main.cc:412)
ord::tclAppInit(Tcl_Interp*) (/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/OpenROAD/src/Main.cc:440)
Tcl_MainEx (@Tcl_MainEx:111)

[maliberty]

You could try disabling each of these in turn to localize the cause

if {$::env(GPL_ROUTABILITY_DRIVEN)} {
    append global_placement_args " -routability_driven"
}
if {$::env(GPL_TIMING_DRIVEN)} {
    append global_placement_args " -timing_driven"
}

The stacks in rsz/sta are related to timing_driven. If you see a stack in grt that is related to routability_driven.

[oharboe]

Worked! :-)

I'm doing floorplanning right now, so I plan to return to deal with this later. Obviously there is a problem that needs to be bottomed out on.

# speed up global placement
export GPL_ROUTABILITY_DRIVEN = 0
export GPL_TIMING_DRIVEN = 0

[QuantamHD]

@oharboe Is this a public test case? I've previously profiled GPL and found that calling into GRT and STA is usually pretty expensive it would be nice to get to the bottom of it.

[oharboe]

@oharboe Is this a public test case? I've previously profiled GPL and found that calling into GRT and STA is usually pretty expensive it would be nice to get to the bottom of it.

I am afraid it is not a public case.