https://open-source-silicon.dev logo
Join Slack
Powered by
The problem I am having is that opentriton gets in...
# openlane
j
The problem I am having is that opentriton gets into an infinite loop trying to read 
/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)
a
How large is merged_unpadded.lef? Might this issue have something to do with https://skywater-pdk.slack.com/archives/C01EX4ATEKF/p1607195676033000?
j
The full chain is 
Makefile
==> 
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()
The file is 47MB long
looking at the details, everything is what I expected
a
I really think it's the issue I linked above. Also 47MB LEF file is too large for small blocks. It should be ~4-5MB or so. Specifically, check if you had this setting enabled: https://skywater-pdk.slack.com/archives/C01EX4ATEKF/p1607204541043200
j
Thanks for the tip! I checked 
openlane/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...
No - there were no 
MAGIC
settings for 
user_proj_example
either. But it does have over 30 thousand standard cells in it
To continue the results of my investigation: I copied (with slight fixes) the example lefreader program given in the appendix of the user manual for lefdef in the coriolis library and so was able to call lefyyparse() on my file and it worked just fine. I noticed some magic numbers at the start of 
lef.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 loop
I was able to run OpenTriton in gdb and verified that 
LefDefParser::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.
I thought it might be in a infinite loop, but now I am not sure. I more carefully looked at the 
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 layers
Previously I had lots of problems with the tools generating fillers and well taps throughout the whole wrapper. Hmmm... I fixed that, but it might be a good idea to not leave any files around from previous runs....
No, clearing all files from previous runs did not help. I will leave OpenTriton running for at least 8 hours since perhaps that is the time it needs to go from an 8 line PIN definition to a 400,000 line one
a
@Jecel Assumpção Jr: If you share your current run, I can have a closer look at it, but in any case, 45MB is just too much for a small block. Most of it should have been abstracted away; if not, then something went wrong somewhere.
j
I was trying to use 
config.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 them
a
@Jecel Assumpção Jr: I am really not sure why you're getting 400k rectangles for power nets if the LEF is written using 
-hide
in magic. The whole thing should be at most a couple hundred KBytes...
j
Thanks, I will look into that
mergelef.py
is run twice to create the file
3 Views
Open in Slack
PreviousNext
Powered by