Native windows Vivado and WSL2 Litex build fails to find toolchain

[exitrip]

Kinda an edge case, but I'm also not sure how friendly Vivado's linux installer would work with WSL2...

calling python3 -m litex_boards.targets.colorlight_i9plus --build --toolchain=vivado in an otherwise working (with Lattice chips) Litex WSL2 install fails to properly use the windows exe tools.

I can't find any place Litex calls rdiArgs.sh, to try to point to rdiArgs.bat

I'm not sure about the relationship between rdiArgs (which is the only place I can find the string lnx64) and how Litex handles path resolution. Nor do I know anything about how Vivado uses Java...

/mnt/d/Xilinx/Vivado/2023.2/bin/rdiArgs.sh: line 38: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
WARNING: /mnt/d/Xilinx/Vivado/2023.2/tps/lnx64/jre17.0.7_7 does not exist.
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
ERROR: Could not find 64-bit executable.
ERROR: /mnt/d/Xilinx/Vivado/2023.2/bin/unwrapped/lnx64.o/vivado does not exist

Does anyone have experience installing Vivado in WSL?

[linhz0hz]

I have similar questions with gowin toolchain actually. How do you pass a path inside WSL to a windows program so it is properly identified? Some searching online suggested that you can reference it using \wsl.localhost\Ubuntu\home\

On the other hand, I am checking if litex can be made to work with powershell directly.

[nmk456]

I've been trying to do this as well and ran into the same issue. I did some testing and found out it's because litex sees it's in WSL and tries to call the linux command to run Vivado (vivado) instead of the Windows one (vivado.bat). Every Vivado installation has both of these scripts included, but not the respective binaries for other platforms. That's what the lnx64.o/vivado does not exist error is about, it's looking for the Linux lnx64.o binary when only the Windows win64.o one exists.

I tried to work around this by running the litex build and modifying the build.sh script it generated to use the Windows version of the command. I was able to get it to run successfully with this process:

• Set working directory to be in the Windows filesystem, not WSL's. So the path must be something like /mnt/c/Users/username/whatever if you want it to be in your normal Windows user folder. This is because the Windows command processor doesn't support WSL paths.
• Attempt a litex build, ex: python3 -m litex_boards.targets.digilent_arty --build --no-compile-software
• After the build fails, edit build/gateware/build_digilent_arty.sh and change the line vivado -mode batch -source digilent_arty.tcl to cmd.exe /c vivado.bat -mode batch -source digilent_arty.tcl
• Modify digilent_arty.tcl to use Windows paths instead of WSL paths for the verilog source files. Like before, all files must be in the Windows filesystem, not WSL, because Vivado is running in Windows and doesn't understand WSL paths. I had to copy VexRiscv.v into the build directory in this case. The litex generated paths are absolute paths, using relative paths instead makes this simpler because they will be the same in both Windows and WSL.
• Run build_digilent_arty.sh, it should work now

This is a somewhat involved process but I'd like to be able to use WSL so I might make a PR to implement this in vivado.py if I have the time (and if I can figure out how). It would be nice if there was a way to get around the whole path issue, because that would make this much easier.