run VUnit from WSL with Modelsim installed in windows

[Ahmad-Zaklouta]

I have VUnit installed in WSL2 and Modelsim intel edition in windows 10.
I set VUNIT_SIMULATOR and VUNIT_MODELSIM_PATH in etc/enviroment and etc/profile and ~/.bashrc to:

VUNIT_SIMULATOR="modelsim"
VUNIT_MODELSIM_PATH="/mnt/c/intelFPGA_pro/19.2/modelsim_ase/win32aloem/"

I have been trying to run it but it complains that it could not find vcom nor vlib.
FileNotFoundError: [Errno 2] No such file or directory: /mnt/c/intelFPGA_pro/19.2/modelsim_ase/win32aloem/vcom': '/mnt/c/intelFPGA_pro/19.2/modelsim_ase/win32aloem/vcom'

it seems that WSL2 cannot pick the extension, @eine advised me to create symlink for that and then this error has been fixed but now when I run: python run.py it gives this error:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/ui/__init__.py", line 726, in main
    all_ok = self._main(post_run)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/ui/__init__.py", line 772, in _main
    all_ok = self._main_run(post_run)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/ui/__init__.py", line 801, in _main_run
    self._compile(simulator_if)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/ui/__init__.py", line 951, in _compile
    target_files=target_files,
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/sim_if/__init__.py", line 211, in compile_project
    self.setup_library_mapping(project)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/sim_if/modelsim.py", line 136, in setup_library_mapping
    self.create_library(library.name, library.directory, mapped_libraries)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/sim_if/modelsim.py", line 219, in create_library
    proc.consume_output(callback=None)
  File "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-py3.6.egg/vunit/ostools.py", line 208, in consume_output
    raise Process.NonZeroExitCode
vunit.ostools.Process.NonZeroExitCode```

[eine]

Ref #539

[sbedt]

I was trying to get vunit with modelsim working under WSL and ran into the same issues. Note this is vunit installed under WSL calling modelsim installed under windows. Doing some "printf" debugging, I found that the modelsim executables don't seem to be able to handle the absolute path names as WSL mounts, which is how vunit seems to handle the file names for libraries, etc., but is able to handle relative path names. e.g. my D: drive is accessible in WSL as /mnt/d.

$ pwd
/mnt/d/local/test/
$ /mnt/c/modeltech_pe_10.6/win32pe/vlib -unix /mnt/d/local/test/vunit_out/modelsim/libraries/lib
** Error: (vlib-35) Failed to create directory "/mnt/d/local/test/vunit_out/modelsim/libraries/vunit_lib".
No such file or directory. (errno = ENOENT)
$ echo $?
7
$ /mnt/c/modeltech_pe_10.6/win32pe/vlib -unix ./vunit_out/modelsim/libraries/lib
$ echo $?
0

I was able to make progress by hacking at vunit/sim_if/model_sim.py and adding os.path.relpath() around the path variables in create_library() and compile_vhdl_file_command().

Unfortunately, I ran into another roadblock when vunit is trying to compile the vunit_lib files (starting with the string_ops.vhd).

Compiling into vunit_lib: ../../../../home/sbedt/.local/lib/python3.6/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd                        failed
=== Command used: ===
/mnt/c/modeltech_pe_10.6/win32pe/vcom -quiet -modelsimini vunit_out/modelsim/modelsim.ini -2008 -work vunit_lib ../../../../home/sbedt/.local/lib/python3.6/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd

=== Command output: ===
** Error: (vcom-7) Failed to open design unit file "../../../../home/sbedt/.local/lib/python3.6/site-packages/vunit/vhdl/string_ops/src/string_ops.vhd" in read mode.
No such file or directory. (errno = ENOENT)

Even though its path is relative, I think, because it's installed in my home directory under WSL and not the "normal" Windows filesystem, that my Windows modelsim can't find the file. Would be interested to hear any solutions and maybe my above explorations will help others.

[eine]

It seems that several of you are hitting issues when trying to use VUnit in a WSL1 or WSL2 terminal, along with a Windows version of ModelSim.

My first suggestion would be for you to try the Linux version of ModelSim instead. That should avoid issues with path types.

A similar problem exists with MSYS2/MINGW. In that case, there are mechanisms for converting paths from linux to windows format, and the other way round. In fact, it can be done implicitly and/or explicitly. It would be interesting to investigate whether WSL includes any similar mechanism. Otherwise, VUnit might need to be patched for handling linux paths internally, but converting them before calling an external windows simulator.

Overall, I wonder why are you using WSL, if the simulator is installed on Windows. Is it for avoiding installing Python on Windows?

Even though its path is relative, I think, because it's installed in my home directory under WSL and not the "normal" Windows filesystem, that my Windows modelsim can't find the file. Would be interested to hear any solutions and maybe my above explorations will help others.

My feeling is that this use case goes beyond WSL's intended usage. You installed VUnit inside a virtual machine, you mounted an external directory inside the virtual machine and you are asking a binary from that directory to access the home of the virtual machine. Theoretically, it should work, because the "environment" when you execute the binary should be the virtual machine. It does definitely work if I use a docker container instead of WSL. However, in Docker it's easier to understand what's going on, because the binaries/executables need to be linux binaries. Yet, who knows the details of how Microsoft implemented the "transparent binding". Windows binaries are not executed inside the virtual machine, but on the host; and some translation layer needs to exist for dealing with file system, signals, etc.

@sbedt, I would suggest trying to isolate the problem:

/mnt/c/modeltech_pe_10.6/win32pe/vcom -quiet -2008 -work my_lib ~/my_file.vhd

Then, try a similar command with any other windows tool, to ensure that the problem is not specific about ModelSim.

[GlenNicholls]

So I'm testing this out and I'm not seeing the above issues after creating symlinks for vcom and vlib. For reference, I'm using modelsim DLX 2019.4 and WSL kernel:

PS P:\> wsl --status
Default Distribution: Ubuntu-20.04
Default Version: 2

Windows Subsystem for Linux was last updated on 5/31/2022
The Windows Subsystem for Linux kernel can be manually updated with 'wsl --update', but automatic updates cannot occur due to your system settings.
To receive automatic kernel updates, please enable the Windows Update setting: 'Receive updates for other Microsoft products when you update Windows'.
For more information please visit https://aka.ms/wsl2kernel.

Kernel version: 5.10.102.1

However, I get a different error:

=== Command used: ===
/mnt/c/Modelsim/modelsim_dlx64_2019.4/win64pe/vcom -quiet -modelsimini /mnt/blah/vunit_out/modelsim/modelsim.ini -2008 -work COMMON /mnt/ssd/gnicholls/blah/src/blah.vhd

=== Command output: ===
** Error: (vcom-1598) Library "std" not found.
** Note: VHDL Compiler exiting

It appears that $MODEL_TECH defined in the modelsim.ini might be causing issues:

[Version]
iniversion = "2019.4"

[Library]
std = $MODEL_TECH/../std
ieee = $MODEL_TECH/../ieee
vital2000 = $MODEL_TECH/../vital2000
verilog = $MODEL_TECH/../verilog
std_developerskit = $MODEL_TECH/../std_developerskit
synopsys = $MODEL_TECH/../synopsys
modelsim_lib = $MODEL_TECH/../modelsim_lib
sv_std = $MODEL_TECH/../sv_std
mtirnm = $MODEL_TECH/../rnm
floatfixlib = $MODEL_TECH/../floatfixlib
osvvm = /mnt/blah/vunit_out/modelsim/libraries/osvvm

I'm trying to figure out what $MODEL_TECH is, but I'm assuming that it's being set to C:\Modelsim\... instead of /mnt/c/Modelsim/...

[GlenNicholls]

I attempted to create symbolic links in the install dirs and found that running those exe's on windows didn't work and led to confusing errors. I found microsoft/WSL#2003 (comment) but that doesn't appear to work since VUnit uses the full path instead of adding the path and calling the exe by name only. I changed to using an alias which appears to work but I don't really like that solution.

@LarsAsplund @umarcor what are your thoughts about adding the tool path to python's path and calling Popen/subprocess with the exe by name only? Currently, VUnit does $ C:\Modelsim\modelsim_dlx64_2019.4\win64pe\vcom .... Instead, I propose VUnit add the path via sys.path.append() followed by run(shlex.split("vcom <options>"))

IMO, I think this is actually a bug. I find it weird that VUnit would use C:\Modelsim\modelsim_dlx64_2019.4\win64pe\vcom instead of C:\Modelsim\modelsim_dlx64_2019.4\win64pe\vcom.exe on Windows since the former doesn't exist. For example, python directly makes sense, but C:\blah\python3\blah\python does not and you can see this in other tools like tox when they use the full path to call an executable as they usually include the extension:

[29436] D:\tmp\tox_example\.tox$ 'c:\users\glen.nicholls\appdata\local\programs\python\python37\python.exe' -m virtualenv --no-download --python 'c:\users\glen.nicholls\appdata\local\programs\python\python37\python.exe'

[umarcor]

@GlenNicholls if modelsim is not using the .exe to call binaries on Windows, I agree it should be fixed. Some environments, such as MSYS2, can handle executables without extension (e.g. /c/Modelsim/modelsim_dlx64_2019.4/win64pe/vcom) but it will work if the extension is provided.

[ajeethakv]

I believe I now have a working setup of WSL + modelsim installed on Windows - for both VHDL & Verilog + VUnit flows. Here are the hacks/fixes that I did so far:

file: vsim_simulator_mixin.py
    def __init__(self, prefix, persistent, sim_cfg_file_name):
        if (prefix is None):
          prefix = ""

Somehow this prefix is None in my case and that led to weird errors. Maybe @LarsAsplund can throw more light on the intended prefix value.

Also I hacked the vsim to be vsim.exe inside that same file, but am sure I can add a OS check - something like:

platform.release()

and add .exe only for WSL. Is this of interest as PR @LarsAsplund ?

Regards

[ajeethakv]

My fixes are at: master...ajeethakv:vunit:wsl_mti (https://github.com/ajeethakv/vunit/tree/wsl_mti)

Regards