-
How can I use "check_drc"?
/usr/include/c++/10/bits/stl_vector.h:1063: 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# 0x000055F65D6A0236 in openroad
1# 0x00007F3C42497D60 in /lib/x86_64-linux-gnu/libc.so.6
2# gsignal in /lib/x86_64-linux-gnu/libc.so.6
3# abort in /lib/x86_64-linux-gnu/libc.so.6
4# 0x000055F65D6A08A2 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::checkDRC(char const*, int, int, int, int) in openroad
9# 0x000055F65DEBB7C8 in openroad
10# TclNRRunCallbacks in /lib/x86_64-linux-gnu/libtcl8.6.so
11# Tcl_RecordAndEvalObj in /lib/x86_64-linux-gnu/libtcl8.6.so
12# Tcl_MainEx in /lib/x86_64-linux-gnu/libtcl8.6.so
13# main in openroad
14# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
15# _start in openroad
[1] 4098007 abort openroad |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
Be aware check_drc is not a general purpose checker and is only verifying the signal routing according to LEF. It is expecting to see guides as well so you could either
1 is probably simpler. |
Beta Was this translation helpful? Give feedback.
-
After reviewing the source code, I noticed that the I would like to understand which design rules OpenROAD currently supports for checking. Where can I find a comprehensive list Could you please advise where I should look to investigate this further? Thank you for your clarification! |
Beta Was this translation helpful? Give feedback.
-
It is not a general purpose drc engine but the engine used by the detailed router. It will not report violation between fixed objects nor see inside a LEF abstract for detailed checking. It isn't a replacement for a tool like klayout or magic for gds verification. There is no official write up for exactly which parts of LEF are supported but we tend to give warnings for unknown constructs. |
Beta Was this translation helpful? Give feedback.
Be aware check_drc is not a general purpose checker and is only verifying the signal routing according to LEF. It is expecting to see guides as well so you could either
1 is probably simpler.