StanfordAHA/garnet

mflowgen: gdsmerge/outputs needs input from stdin?

Opened this issue · 1 comments

steveri commented

When I run mflowgen e.g. 'make mentor-calibre-drc' from my script, in the background, like so:

make mentor-calibre-drc | tee make.log &

It goes merrily along for an hour or so until it hits make mentor-calibre-gdsmerge/outputs

  + make mentor-calibre-drc
    08:41 make 2-tsmc16
    08:41 make 2-tsmc16/outputs
    08:41 make 0-rtl/outputs
    08:42 make 1-constraints/outputs
    08:42 make 6-synopsys-dc-synthesis/inputs
    ...
    09:12 make 16-mentor-calibre-gdsmerge/inputs
    09:12 make 16-mentor-calibre-gdsmerge/outputs

  [1]+  Stopped     make mentor-calibre-drc

At this point it stops, apparently waiting for user input of some sort. If I foreground the job, hit a couple of carriage-returns, then background again, it completes successfully.

  [1]+  Running     make mentor-calibre-drc &
    10:11 make 18-mentor-calibre-drc/inputs
    10:11 make 18-mentor-calibre-drc/outputs
    DONE

I assume there is an easy workaround, something like

make mentor-calibre-drc < /dev/null | tee make.log &

, which I am about to work on now, but that's kind of ugly.

Does anyone know what/why this wants from stdin and/or how to prevent it? And/or am I doing something wrong?

ctorng commented

I don't expect that behavior...

The gds merge step commands are very simple:

I haven't run into this myself before. I usually don't pipe the make command to a tee though, since each step already logs its output (in mflowgen-run.log). The gds merge step is the only step with commands that pipe to a tee, but that is all in a subshell so it should not matter from your end. Also a tee should not cause it to wait for stdin.

My guess is there is some local one-time setup that Calibre pings you for, and this will not happen again?

Maybe your logs (or that step's mflowgen-run.log) shows what it was waiting for?