[vtr_flow] Changed Triggers for Second Run #2923
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when running the VPR stage of the vtr_flow script, if you are routing at a fixed channel width and you have "--route" or "--analysis" in the command, it will run the VPR stage twice with the exact same arguments. This is unnecessary and can make some of the runs 2x longer than they need to be.
The purpose of running the VPR flow twice is that the second time would load in the temporary files produced by the first run to ensure they are the same values. It appears as though route and analysis used to be part of this check; however it is no longer being used. I checked the second run code and having the --route or --analysis flag set has no affect on the second run's arguments; so the exact same run is dispatched.
I looked through all the regression tests and only found one testcase that used either of these options; which may be the reason this was never caught.
This is useful for the AP flow since, to use the AP flow, we need to specify the --analytical_place flow which inherently does not perfrom routing. So we have to add --route to our arguments. I noticed that these runs took 2x longer than they should and found this issue.
The code that triggers the second run can be found here:
vtr-verilog-to-routing/vtr_flow/scripts/python_libs/vtr/flow.py
Lines 295 to 338 in 12c4600
The second run is performed here:
vtr-verilog-to-routing/vtr_flow/scripts/python_libs/vtr/vpr/vpr.py
Lines 276 to 341 in 12c4600
Notice that the second run's args only change based on the router lookahead and rr graph.