Copy & pasting openroad command lines from bash

[oharboe]

If I copy and paste this command line from the bash log, then it will fail:

openroad -exit -no_init  ./scripts/detail_route.tcl -metrics ./logs/asap7/ce-array/base/5_2_TritonRoute.json

Is there a reason not to modify the build scripts, such that only command line arguments is used to transfer information to the openroad command lines, such that it is possible to copy and paste and run these commands locally?

Currently environment variables are used as global variables, so it's not possible to see what really goes into the openroad application here.

As well as making debugging and fiddling with a step easier, this would be especially nice if one is using a docker image to build, but would like to use the local openroad GUI app.

The openroad GUI app when run from docker crashes The-OpenROAD-Project/OpenROAD#2675

[vijayank88]

@oharboe
Can you share what's the error got while using above command?

[vijayank88]

@vvbandeira FYI.,

[vvbandeira]

My thinking is that the make scripts should write e.g. a json (or yaml, easier to read) file that is read in by this step, rather than use environment variables.

This would be nice IMO, but also, to my knowledge, there isn't an easy way to accomplish this. My suggestion would be to use make command which starts openroad with the correct variables set.

[oharboe]

This doesnt cover the use-case of running openroad in a debugger, like vscode.

[rovinski]

Using make *_issue where * is the script name will create a reproducible issue. In that tar file, there are files created which capture the make environment and can be used to set up the state in other programs (issue.sh, issue.tcl, and issue.gdb).

So make detail_route_issue should get you what you need.

[oharboe]

Using make *_issue where * is the script name will create a reproducible issue. In that tar file, there are files created which capture the make environment and can be used to set up the state in other programs (issue.sh, issue.tcl, and issue.gdb).

So make detail_route_issue should get you what you need.

Indeed it gives me all the fiddly bits I need...

So I can run:

make DESIGN_CONFIG=designs/asap7/mock-array-big/Element/config.mk gui_issue

This produces a .tcl file that sets the variables as well as variants thereof(gdb, bash script I can source, etc.)

The command generated by the makefile is:

ODB_FILE=./results/asap7/mock-array-big_Element/base/2_floorplan.odb /home/oyvind/ascenium/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad -gui  ./scripts/gui.tcl

So it seems like we're a step or two away from having the Makefile issue command lines that will work if you copy and paste them into a debugger setup, like Visual Studio Code.

Ideall I'd like to see that the command line I can copy and paste into Visual Studio Code debugger looks something like:

/home/oyvind/ascenium/OpenROAD-flow-scripts/tools/install/OpenROAD/bin/openroad -gui  vars.tcl ./scripts/gui.tcl ./results/asap7/mock-array-big_Element/base/2_floorplan.odb 

Where:

• vars.tcl is generated by the code that implements make gui_issue. This script takes it takes a script as arguments and forwards the rest of the arguments to the invoked script.
• gui.tcl is updated to take the .odb file to be opened from the arguments instead of an environment variable

I think this would improve usability and be more immediately obvious without digging through the Makefile or knowing about make foo_issue.

Thoughts?

[maliberty]

The openroad app needs a more generic way to pass user flags into the script to make this possible. @proppy did some of this work for Python but we don't have an equivalent for TCL.

If you had that then you could convert all the data passed by envars from make to OR into command line args that the scripts could pick up. It would be a nice enhancement if someone wants to tackle it for both languages. The ORFS part would be pretty mechanical, if tedious.

[proppy]

do we already have an issue (not a discussion), tracking that work for TCL?

[maliberty]

No as it has never been planned in the past.