maliberty
commented
6 months ago @luis201420 is working on rewriting this chunk of code. I believe that will solve you problem but it will be a bit until the new code is ready.
Closed MichaelBell closed 4 months ago
maliberty
commented
6 months ago @luis201420 is working on rewriting this chunk of code. I believe that will solve you problem but it will be a bit until the new code is ready.
maliberty
commented
6 months ago The general goal is to no longer call orderWires during antenna repair
dlmiles
commented
6 months ago When investigating this, the following assertion is triggered.
Is the frame posted before (containing db::orderWires(...) call a symptom, while this frame is closer to the cause ?
@maliberty no sign of db::orderWires() here, please re-evaluate if the removal of the call will address this problem, or if I should continue to investigate. Thanks
FWIW this problem/frame that looks like this can be demonstrated in many versions of OR going back the past 6 to 9 months. High congestion maybe a contributing factor.
[INFO GRT-0006] Repairing antennas, iteration 3.
[INFO GRT-0043] No OR_DEFAULT vias defined.
openroad: /openroad/src/odb/src/db/dbWireCodec.cpp:393: int odb::dbWireEncoder::addTechVia(odb::dbTechVia*): Assertion `0' failed.
Signal 6 received
Stack trace:
0# 0x0000000004065175 in openroad
1# 0x00007F5413F2B400 in /lib64/libc.so.6
2# gsignal in /lib64/libc.so.6
3# abort in /lib64/libc.so.6
4# 0x00007F5413F241A6 in /lib64/libc.so.6
5# 0x00007F5413F24252 in /lib64/libc.so.6
6# odb::dbWireEncoder::addTechVia(odb::dbTechVia*) in openroad
7# grt::RepairAntennas::addWireTerms(grt::Net*, std::vector<grt::GSegment, std::allocator<grt::GSegment> >&, int, int, int, odb::dbTechLayer*, std::map<grt::RoutePt, grt::RoutePtPins, std::less<grt::RoutePt>, std::allocator<std::pair<grt::RoutePt const, grt::RoutePtPins> > >&, odb::dbWireEncoder&, std::map<int, odb::dbTechVia*, std::less<int>, std::allocator<std::pair<int const, odb::dbTechVia*> > >&, bool) in openroad
8# grt::RepairAntennas::makeNetWire(odb::dbNet*, std::vector<grt::GSegment, std::allocator<grt::GSegment> >&, std::map<int, odb::dbTechVia*, std::less<int>, std::allocator<std::pair<int const, odb::dbTechVia*> > >&) in openroad
9# grt::RepairAntennas::makeNetWires(std::map<odb::dbNet*, std::vector<grt::GSegment, std::allocator<grt::GSegment> >, grt::cmpById, std::allocator<std::pair<odb::dbNet* const, std::vector<grt::GSegment, std::allocator<grt::GSegment> > > > >&, int) in openroad
10# grt::RepairAntennas::checkAntennaViolations(std::map<odb::dbNet*, std::vector<grt::GSegment, std::allocator<grt::GSegment> >, grt::cmpById, std::allocator<std::pair<odb::dbNet* const, std::vector<grt::GSegment, std::allocator<grt::GSegment> > > > >&, int, odb::dbMTerm*, float) in openroad
11# grt::GlobalRouter::repairAntennas(odb::dbMTerm*, int, float) in openroad
12# grt::repair_antennas(odb::dbMTerm*, int, float) in openroad
...The problem is order wires and is understood.
MichaelBell
commented
6 months ago This is causing problems with a number of Tiny Tapeout 6 designs, now that Tiny Tapeout has moved to an OpenLane version with the bug present.
This patch seems to work (or at least resolve the crash) on at least a couple of designs, suggesting the problem might be happening in makeNetWires, as dlmiles suggested above. But none of us in the Tiny Tapeout community fully understand the implications. Any comment on whether this is a good idea would be welcome!
https://github.com/obriensp/OpenROAD/commit/d1f0b60d7b31393ec0afb8f96e1ca02bb465b3fc
maliberty
commented
6 months ago We are in the midst of fixing another bug in the same spot of code so results will probably change again. In general such things are prone to fix one design and break another due to the brittle nature of order_wires. The real solution is still in progress but you should use whatever local methods you can until then.
dlmiles
commented
5 months ago This recent fix just landed in OR looks the same to me as the patch from this comment I quote here.
eder-matheus
commented
4 months ago @MichaelBell Could you try the latest version of OpenROAD? We've merged the new antenna checker code that don't use orderWires, so this crash should not be happening anymore.
I've tried to run your attached testcase, but it fails with a missing SDC file.
MichaelBell
commented
4 months ago Thanks, I'll take a look.
At a guess of what's going wrong with the SDC file - it should be using base.sdc from my src directory, but that does read_sdc $::env(OPENLANE_ROOT)/scripts/base.sdc, maybe OPENLANE_ROOT isn't set in your environment?
eder-matheus
commented
4 months ago Thanks, I'll take a look.
At a guess of what's going wrong with the SDC file - it should be using
base.sdcfrom mysrcdirectory, but that doesread_sdc $::env(OPENLANE_ROOT)/scripts/base.sdc, maybeOPENLANE_ROOTisn't set in your environment?
Yeah, that's the case. I tried to find the file under openlane/scripts but couldn't see it.
MichaelBell
commented
4 months ago Weird, it should be here: https://github.com/The-OpenROAD-Project/OpenLane/blob/master/scripts/base.sdc
eder-matheus
commented
4 months ago Weird, it should be here: https://github.com/The-OpenROAD-Project/OpenLane/blob/master/scripts/base.sdc
@MichaelBell It wasn't in the test case you attached. Either way, I'll close this issue for now, but if you have any other crashes, feel free to reopen it or create a new issue.
Describe the bug
While running the Global Routing step, on certain designs a crash occurs in repair antennas. This only seems to happen if more than one iteration is required. This seems very similar to #4471, but I have confirmed it still happens with a very recent version of OpenROAD.
Expected Behavior
The global router should not crash
OpenROAD Environment
OpenLane Environment
To Reproduce
Clone the openroad-antenna-bug branch of https://github.com/MichaelBell/tt06-tinyQV recursively Follow https://docs.google.com/document/d/1aUUZ1jthRpg4QURIIyzlOaPWlmQzr-jBn3wZipVUPt4/edit#heading=h.wwc5ldl01nl5 to set up the OpenLane flow for TinyTapeout, with the following changes:
Run:
I've also attached a zip of the issue reproducible folder. issue_reproducible.zip
Relevant log output
Screenshots
No response
Additional Context
This issue also caused failures for certain Tiny Tapeout 05 projects (that previously succeeded) when testing the 2024.03.12 tag of OpenLane: https://github.com/TinyTapeout/tinytapeout-05-reharden/actions/runs/8264211005/job/22609263738 https://github.com/TinyTapeout/tinytapeout-05-reharden/actions/runs/8264211005/job/22609256508