The-OpenROAD-Project
Detailed routing failed: Signal 6 received Stack trace
Description
The tool crashed at the detailed routing step with the stack trace shown in the log.
The project that was run can be found here: https://github.com/Asma-Mohsin/FPGA_IGNITE_2024/commit/e468a53fc7af2a249bea2a6f9a4ebab1a43ea5f4
Did we possibly do anything wrong or is this a bug? If we did anything wrong, would it be possible to catch this as an error?
If any further information is required, please tell.
Expected Behavior
Succeed detailed routing or get an error message.
Environment report
How is this done when using the Caravel setup?
https://github.com/efabless/caravel_user_project
Reproduction material
Relevant log output
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_vector.h:950: std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp = std::unique_ptr<fr::frAccessPoint>; _Alloc = std::allocator<std::unique_ptr<fr::frAccessPoint> >; std::vector<_Tp, _Alloc>::const_reference = const std::unique_ptr<fr::frAccessPoint>&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Signal 6 received
Stack trace:
0# 0x0000000000D429A7 in openroad
1# 0x00007F3A6D43F400 in /lib64/libc.so.6
2# gsignal in /lib64/libc.so.6
3# abort in /lib64/libc.so.6
4# 0x0000000000D42A82 in openroad
5# fr::io::Parser::initRPin_rpin() in openroad
6# fr::io::Parser::initRPin() in openroad
7# triton_route::TritonRoute::initGuide() in openroad
8# triton_route::TritonRoute::main() in openroad
9# detailed_route_cmd(char const*, char const*, char const*, char const*, char const*, bool, int, char const*, char const*, int, double, char const*, char const*, int, bool, bool, bool, int, bool, char const*) in openroad
10# 0x00000000013DF2AD in openroad
11# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
12# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
13# TclObjInterpProcCore in /lib64/libtcl8.5.so
14# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
15# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
16# 0x00007F3A71FC0647 in /lib64/libtcl8.5.so
17# TclEvalObjEx in /lib64/libtcl8.5.so
18# 0x00007F3A71FFB27F in /lib64/libtcl8.5.so
19# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
20# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
21# 0x00007F3A71FC0647 in /lib64/libtcl8.5.so
22# TclEvalObjEx in /lib64/libtcl8.5.so
23# 0x00007F3A71F7B1D0 in /lib64/libtcl8.5.so
24# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
25# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
26# 0x00007F3A71FC0647 in /lib64/libtcl8.5.so
27# TclEvalObjEx in /lib64/libtcl8.5.so
28# 0x00007F3A71F7EF00 in /lib64/libtcl8.5.so
29# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
30# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
31# TclObjInterpProcCore in /lib64/libtcl8.5.so
32# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
33# 0x00007F3A71FB836C in /lib64/libtcl8.5.so
34# TclObjInterpProcCore in /lib64/libtcl8.5.so
35# 0x00007F3A71F73EB2 in /lib64/libtcl8.5.so
36# 0x00007F3A71F74F1E in /lib64/libtcl8.5.so
37# Tcl_EvalEx in /lib64/libtcl8.5.so
38# Tcl_Eval in /lib64/libtcl8.5.so
39# sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) in openroad
40# ord::tclAppInit(Tcl_Interp*) in openroad
41# Tcl_Main in /lib64/libtcl8.5.so
42# main in openroad
43# __libc_start_main in /lib64/libc.so.6
44# 0x0000000000D3C6C7 in openroad
@Asma-Mohsin Hello. I have a couple of questions:
- When I tried the provided commit, I had to make modifications to the configuration file. I disable linting because if failed and I have to include additional verilog files. Are you sure you are providing the correct commit for the repo?
- Which OpenLane version are you running? Even after the modifications mentioned above I faced different issues during synthesis and never got past it.
Hey @kareefardi Thankyou for taking the time to look into it. We figured out what was causing the issue. So actually we have blockRAM macro in our design. We have two versions for this macro with different pin length and some other changes. So by mistake we put them in the same folder and the tool was reading both and merging them and in the resultant gds the pins were overlapping. It was a mistake on our end, but maybe a feature could be added to the tool so that it gives some kind of warning for this case?
Should be resolved by using macros object in LibreLane if you ever get around to migrating to that.
