Bazel, build failures and reports

[oharboe]

I have created a wafer thin Bazel layer on top of ORFS, which works pretty well.

My main goal was to share and manage artifacts(macros) across developer machines as well as being able to quickly pull down and examine build results locally after having built designs in our CI server.

However, I'm running into an impedance match between the ORFS workflow and Bazel:

One of the main activities when working with ORFS is that I would like to have artifacts for logs and reports in the case of failure.

Bazel on the other hand, balks at the idea of generating artifacts in the case of failure and neither does Bazel embrace the idea of optional outputs.

Example use case:

• Do detailed routing on a pull request overnight, detailed routing fails with DRC errors
• In the morning, run the bazel build command locally
• Open global routing .odb file, load DRC error report from detailed routing

So how can this be resolved?

To Bazel's mind, this has to be resolved in ORFS.

Change detailed routing step as follows:

• Always generate .odb and .drc file, even in the case of success failure. The .odb file here would ideally be a snapshot(?) of how far the detailed routing got so that it is easier to see what the .drc file is referring to.
• Add a check detailed routing step that fails if detailed routing failed. This step would have to generate a mock-ok file marker

Thoughts?

[maliberty]

When the router ends with drcs errors you do get a .odb today, no?

[oharboe]

Detailed router, yes, I get an .odb file, global router no. To view the global router congestion.rpt, I use the 4_cts.odb

[oharboe]

In geoscience, which also has runs, like reservoir simulations, that runs for days and weeks, the exit code is not used to indicate a failure(like didn't find oil). Rather the simulation runs successfully and then there's various kinds of reporting that can be run aftewards(check_if_found_oil), which can produce non-zero exit codes. A non-zero exit code during the simulation runs are then reserved for catastrophic errors like segfaults, couldn't find files, syntax errors and the like.

Perhaps a similar approach to global routing would make sense in ORFS?

Global, detailed routing always completes without exit code and always leaves behind the same artifacts(empty .drc reports in the case of no errros), but there is a separate "check_route" target that checks if the global and detailed routing was successful.

gui_5_1_grt.odb and gui_5_2_route.odb are used to inspect the .drc errors for those stages respectively.

[maliberty]

It depends on the nature of the problem. Flow steps often consist of many commands. If none of them are allowed to fail then all the downstream commands will have to deal with potentially malformed or missing data. Is this proposal grt specific or would it apply to every command?

[maliberty]

For example does repair_antennas make any sense after grt fails?

[oharboe]

i dont know, but the point is I would like to have artifacts for a failed step.

Let's say that the "place" target fails on the CI server, then I still want artifacts and reports to investigate by running place locally to download results and reports and run gui_place locally.

This means that ORFS would have to be modified to always succeed on the place target and generate reports and have the route target depend on check_place.

Similarly repair_antennas would not run if the preceeding step failed, but there would still be artifacts for the failed step.

This would preserve the behavior today.

[oharboe]

@maliberty Something like this... 8ca904e

[oharboe]

Proposed solution #1596