StanfordAHA/garnet

mflowgen: Makefile error is ignored

Opened this issue · 3 comments

To check Tile_PE for DRC errors I do make mentor-calibre-drc
Along the way, the makefile has to satisfy the dependence make rtl, which fails:

  ...
  cp: cannot create regular file  genesis_verif/garnet.sv : No such file or directory
  cat: genesis_verif/*: No such file or directory

Unfortunately, this does not stop the larger make job, and the error goes streaming past, only to show up later, and somewhat obtusely, when someone/thing tries to access the missing verilog file.

  **ERROR: (IMPSYT-6692): Invalid return code while executing
  'START.tcl' was returned and script processing was stopped. Review
  the following error in 'START.tcl' then restart.
  ...
  innovus 1> 

I think the error comes from this command in the makefile

mkdir -p 0-rtl/outputs && python ../utils/letters.py -c -t rtl 
&& cp -f .mflowgen/0-rtl/mflowgen-run.sh 0-rtl 
&& cp -f .mflowgen/0-rtl/mflowgen-debug.sh 0-rtl 2> /dev/null || true && cd 0-rtl 
&& sh mflowgen-run.sh 2>&1 | tee mflowgen-run.log && cd .. 
&& touch -c 0-rtl/outputs/*

It looks like mflowgen-run.sh calls gen_rtl.sh, which does python garnet.py which is where I'm getting the error (but that's a separate issue).

Anyway: is there an easy way to have the makefile die on error?

More information: it looks like it might be the tee command that hides the error status. I did the following experiment (note tmp.sh always returns error status):

  % (tmp.sh) && echo PASS || echo ERROR
  ERROR

  % (tmp.sh >& /dev/null) && echo PASS || echo ERROR
  ERROR

  % (tmp.sh |& tee /dev/null) && echo PASS || echo ERROR
  PASS

After a little searching, it looks like a solution is to use pipefail setting

  % (set -o pipefail && tmp.sh |& tee /dev/null) && echo PASS || echo ERROR

So. Chris @ctorng . I assume this is an mflowgen thing. Is this a fix you would want to make? That is, instead of generating a makefile command like

mkdir -p 0-rtl/outputs && python this && cp -f that

mflowgen would prepend the pipefail setting e.g.

set -o pipefail && mkdir -p 0-rtl/outputs && python this && cp -f that

?

Thanks Steve! I have been thinking about error-checking for a while. I might try this..

By the way, my current plan is to mirror software as much as possible. Software checks for unintended outcomes with either try/except or with assertions.

  1. The pipefail setting is more in line with try/except, basically by allowing the exception to continue propagating rather than being squashed accidentally along the way.

  2. I was originally leaning toward assertions, which are a type of step that inspect the quality (or correctness) of the preceding step. So you would assert if you find errors, or you can even assert that congestion is below a certain percent.

This is currently in the top 5 of what I want to do next, but it is not the top. Is this something that can wait?

Is this something that can wait?
Yes of course. This by no means a high priority issue for me, I just wanted to get it logged and noted...