Vivado 2020.02 doesn't start syntesis because VRS doesn't exist

Could you show/provide the log leading up to this error? I would like to see what steps and messages are being issued beforehand to better understand what area of the flow it is in.
Also, does this error occur when you issue "aws::make_ipi" for an example design, such as "aws::make_ipi -examples hello_world"?

Hello and thanks for your quick reply. I will provide the log tomorrow but there isn't much to see there. Inside of Vivados Output console, everything looks normal, just like when synthesis process is starting, and all is working fine.

Basically, Vivado gives launch_runs command, and then I see the pop up window for "generate f1 instance", "generate AXI Interconnect", and so on, for all IPs in my design. And then, I get this message in the terminal from where I've started Vivado with vivado -source setup_project.tcl.
Inside of the Vivado GUI, after crash, I can see that Syntesis run is "Queued", and I can see individual runs for each IP, but none have been started, and even though their directories inside of <project_name>.runs have been created, they are all empty.
aws::make_ipi doesn't create problems when it executes, it runs normally, creates a block design and creates an instance of F1, as expected. Although, I believe that somewhere there is a hidden secret on why Vivado switches to HLS flow.

Hello again, I'm providing full log given by Vivado.
Before that, in Ubuntu 20.04 terminal I do:

$ export CL_DIR=$(pwd)  
$ source /tools/Xilinx/Vivado/2020.2/settings64.sh && source /work/aws-fpga/hdk_setup.sh  
$ vivado -source setup_prj.tcl &  

Full log provided here:
https://pastebin.com/7aVk9M45

After this, terminal prints out:
ERROR: Could not find 64-bit executable.
ERROR: /tools/Xilinx/Vitis_HLS/2020.2/bin/unwrapped/lnx64.o/vrs does not exist

Top right corner of Vivado window:
https://imgur.com/PUDw2sn
https://imgur.com/PUDw2sn

Thanks for providing the log. The run starts processes for the IP's in the design, can you check and see if any of the runme logs show the same error you get in the terminal?

/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_f1_inst_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_xbar_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_axi_bram_ctrl_0_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_blk_mem_gen_0_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_axi_bram_ctrl_1_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_auto_pc_0_synth_1/runme.log
/work/vivado_builds/aws_two_bram/AWS_TWO_BRAM/build/AWS_TWO_BRAM.runs/cl_blk_mem_gen_1_0_synth_1/runme.log

Hi, I've double checked and there is no "runme.log" file in any of the locations you propose.
$ cd PRJ_NAME.runs/
$ ls cl_f1_inst_0_synth_1/
cl_f1_inst_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh
$ ls cl_xbar_0_synth_1/
cl_xbar_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh
$ ls cl_axi_bram_ctrl_0_0_synth_1/
cl_axi_bram_ctrl_0_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh
$ ls cl_axi_bram_ctrl_1_0_synth_1
cl_axi_bram_ctrl_1_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh
$ ls cl_blk_mem_gen_0_0_synth_1
cl_blk_mem_gen_0_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh
$ ls cl_auto_pc_0_synth_1/
cl_auto_pc_0.tcl dont_touch.xdc gen_run.xml htr.txt ISEWrap.js ISEWrap.sh rundef.js runme.bat runme.sh

Unfortunately I am not having any luck in reproducing this locally with aws::make_ipi example designs. I am not able to find any script or tool that would reference 'vrs' in that specific location. Could you try building one of the examples just to confirm that it isn't specific to this design?

Hi again kmorris,
I've just tested with aws::make_ipi -example hello_world, then, when it was built launch_runs synth_1 -jobs 4, and the same thing happened.
Meanwhile, I've reverted back to Vivado 2020.1, and it works as expected. I think I'll let this problem be for the moment, as I have much more urgent matters to tend to :)
If you do find some advice or solution please let me know.

Thank you for your desire to help!

Best regards,
jelicicm

I've found the problem with this - the issue is that the <vivado_install_dir>/2020.2/settings.sh has the last line that invokes the setup of environment for Vitis, and I don't have Vitis installed. The line is as such: source /data/tools/xilinx/Vitis_HLS/2020.2/.settings64-Vitis_HLS.sh. Once I removed this line - Vivado flow started working as expected.