vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
fixed sdc file copy and parmys abs path to temp folder issue
This PR resolves issue #2420 and provides a work around to #2302.
Description
The run_vtr_flow.py script was modified to properly copy a specified sdc file into a temp directory regardless of if a relative or absolute path is given to the sdc file. Also, this PR provides a work around for the new requirement by parmys that the path specified for the temp directory be an absolute path. The updated script provides the flow with an absolute path whether an absolute or relative path is specified. Additionally, several command line options are specified in the documentation as having a double --
rather than a single -
(namely fixed_pins
and sdc_file
). The script was modified to provide consistency between how these options are used in both the vpr executable and the script.
How Has This Been Tested?
Several designs were run through the flow using -temp
and --sdc_file
files with both relative and absolute paths.
Types of changes
- [x] Bug fix (change which fixes an issue)
- [ ] New feature (change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Not sure why CI failed -- @WhiteNinjaZ could you relaunch this?
@WhiteNinjaZ : It would be good to move this PR along ... see questions and CI failures above.
Will do, it looks like the logs expired for most of the CI tests so re-running now.
Some jobs timed out ... maybe due to busy CI lately. Re-launching the failed jobs.
Not sure why we have some CI failures; relaunching.
It seems like some tests timed out again, and I can't find the usual button to relaunch the tests. @WhiteNinjaZ @AlexandreSinger : any ideas? This change looks pretty safe (scripting update) given that most CI tests passed and others seem to have timed out. If you can figure out how to relaunch that would be safest, but if @WhiteNinjaZ is pretty sure this works with all tests I could also just merge.
Ah, didn't think of that. Thanks @AlexandreSinger
@vaughnbetz I also saw this PR and was curious why I could not rerun the CI. I believe the reason is because the CI clears runs after a certain period of time (I think a couple of weeks). If a CI run fails for a PR, the CI cannot be rerun the usual way if its been too long (for this PR, the last run was in June).
Normally when this happens I rebase the branch onto Master; however for some reason that button does not work for me on this PR. It may be because the branch is under a different fork (that I do not have the right to modify). So the button to rebase / merge with master was not here for me.
To get around this issue I just closed and reopened the PR. That relaunched the CI. Kinda goofy, but it works. If it fails CI again, I recommend @WhiteNinjaZ to rebase his branch. I am a bit worried about this change in that maybe some CI tests rely on the CLI options to be a certain way and its causing timeouts. The CI will tell.
Thanks @AlexandreSinger . Yes, I was a little worried in case there was something unexpected happening in the tests due to the scripting changes.
@vaughnbetz Yeah there is something in this PR that is causing the strong tests to time out. My guess is the use of os.getcwd()
. These scripts are often run all over the place, so I am not sure if we can guarantee that the current working directory is where we think it is. Looking through the strong tests there are a lot of failures going on. Perhaps this should be rebased onto master and tested locally.
Thanks @AlexandreSinger . @WhiteNinjaZ : can you try this out locally for the strong tests as Alex suggests? Something is going wrong with the strong tests.