Jecel Assumpção Jr
12/10/2020, 8:25 PM/project/openlane/user_project_wrapper/runs/user_project_wrapper/tmp/merged_unpadded.lef
to do the detailed routing, even though magic can read that file just fine (it takes about 27 seconds)Ahmed Ghazy
12/10/2020, 9:39 PMJecel Assumpção Jr
12/10/2020, 9:43 PMMakefile
==> docker run
==> openlane/flow.tcl
==> openlane/scripts/tcl_commands/routing.tcl
==> TritonRoute
(main() in OpenROAD/src/TritonRoute/src/main.cpp
) ==> router.main() in OpenROAD/src/TritonRoute/src/FlexRoute.cpp
==> TritonRoute::init() ==> parser.readLefDef() in OpenROAD/src/TritonRoute/src/io/io.cpp
==> prints "reading lef ..." and does readLef() ==> lefrRead() in coriolis/lefdef/src/lef/lef/lefrReader.cpp
==> lefyyparse()Ahmed Ghazy
12/11/2020, 2:55 PMJecel Assumpção Jr
12/11/2020, 5:21 PMopenlane/user_project_wrapper/runs/user_project_wrapper/config.tcl
just to be sure this setting wasn't sneaking in somehow (I didn't set it manually) and there are no MAGIC
settings at all in there. I see that lef/user_proj_example.lef
is already 45MB. The tools have no problem with that one. Hmmmm.... let me check the full config.tcl
that generated that file...MAGIC
settings for user_proj_example
either. But it does have over 30 thousand standard cells in itlef.y
have been increased over the years so I tried setting them back to the original values in the extremely unlikely case OpenTriton has been compiled against a really old version of the coriolis library (before 2008). The resulting program also read my lef file ok. The program in the appendix uses callbacks that just print things while OpenTriton's callbacks do different things. So lefyyparse() calls code given to it and that code might be getting into the infinite loopLefDefParser::lefyyparse()
calls fr::io::Parser::Callbacks::getLefPins(LefDefParser::lefrCallbackType_e, LefDefParser::lefiPin*, void*)
which in turn calls standard library stuff but does not itself every return.merged_unpadded.lef
in both user_proj_example
(45MB but OpenTriton likes it) and user_project_wrapper
(47MB and which OpenTriton is choking on) and found a significant difference: the latter has definitions for PIN VPWR
and PIN VGDN
which are nearly half a million lines long! Many, many rectangles to nwell and pwell respectively besides other layersAhmed Ghazy
12/14/2020, 12:27 PMJecel Assumpção Jr
12/14/2020, 7:26 PMconfig.tcl
inside user_project_wrapper/
instead of interactive.tcl
and though I did set ::env(FILL_INSERTION) 0
and it seemed to make all those filler cells and ground and power taps go away, I can now see that there is still a problem. The solution I will try now is to go the `interactive.tcl`way and see what that does. I don't think the 47MB file size in itself is a problem since the lef in user_proj_example is only 2MB smaller and it works ok. It is the absurdly larger VPWR and VGND pins that are the problem - I am now convinced there is something that grows with the square of the number of rectangles and with more than 400 thousand rectangles each for those two pins not even 12 hours is enough for OpenTriton to read themAhmed Ghazy
12/15/2020, 8:59 PM-hide
in magic. The whole thing should be at most a couple hundred KBytes...Jecel Assumpção Jr
12/15/2020, 9:09 PMmergelef.py
is run twice to create the file