vsim does not accept -modelsimini parameter on Windows
Asked Answered
S

2

35

I'm using the command line argument -modelsimini <modelsim.ini> to specify my own modelsim.ini file for most QuestaSim / ModelSim executables.

This works perfectly fine on Linux for vcom and vsim, as well as for vcom on Windows. But the Windows vsim aborts and throws an error:

C:\Mentor\QuestaSim64\10.4c\win64\vsim.exe -do "do D:/git/PoC/sim/vSim.batch.tcl" -c -modelsimini D:\git\PoC\temp\precompiled\vsim\modelsim.ini -error 3473 -t 1fs test.arith_prng_tb
Reading C:/Mentor/QuestaSim64/10.4c/tcl/vsim/pref.tcl

# 10.4c

# ** Error: (vsim-7) Failed to open -modelsimini file "{D:\git\PoC\temp\precompiled\vsim\modelsim.ini}" in read mode.
#
# Invalid argument. (errno = EINVAL)
# Error loading design
Error loading design
# Errors: 1, Warnings: 0

The modelsim.ini files exists and has the following content:

[Library]
others = $MODEL_TECH/../modelsim.ini

(This file will contain more lines if vendor tools add their library mappings.)

How can I pass my own modelsim.ini configuration file to vsim.exe?

Siler answered 3/5, 2016 at 23:26 Comment(2)
While I'm not the downvoter, everywhere you see the -modelsimini command line argument described you'll see On Windows systems the path separator should be a forward slash (/). As in ModelSim ® Reference Manual Software Version 10.1c around 10 places. There's at least one place in the Questasim users manual where the same sentence is found (I found it there first). The behavior may not be as strange as you find it.Pirogue
@Gab Sorry. This was not my intention.The reported issue, seems to be more wide spread on SO.Siler
C
5

It is questionable whether this should be considered as a bug or not because TCL requires that file names are specified with forward slashes instead of backward slashes. Of course, one would expect that file-names are handled the same way when calling vcom or vsim. So the solution from this viewpoint is to specify the path with forward slashes:

C:\Mentor\QuestaSim64\10.4c\win64\vsim.exe -do "do D:/git/PoC/sim/vSim.batch.tcl" -c -modelsimini D:/git/PoC/temp/precompiled/vsim/modelsim.ini -error 3473 -t 1fs test.arith_prng_tb

Checked it here with ModelSim 10.1d under Windows and a modelsim.ini in my temporary directory.


Some experiments under the vsim TCL console reveals that -modelsimini file-name is handled differently by the vcom and vsim commands. At first a backslash indicates an escape sequence, a \t in the file-name is expanded to a tab for example:

vcom -modelsimini c:\tmp\modelsim.ini test.vhdl
# ** Error: (vcom-7) Failed to open -modelsimini file "c:   mpmodelsim.ini" in read mode.
# 
# Invalid argument. (errno = EINVAL)
# D:/altera/13.1_web/modelsim_ase/win32aloem/vcom failed.

To prevent this, the argument can be put in curly braces {} for example:

vcom -modelsimini {c:\tmp\modelsim.ini} test.vhdl
# ** Error: (vcom-7) Failed to open -modelsimini file "c:\tmp\modelsim.ini" in read mode.
# 
# No such file or directory. (errno = ENOENT)
# D:/altera/13.1_web/modelsim_ase/win32aloem/vcom failed.

I specified a non-existent file, so that one can see the expansion. If I create the file c:\tmp\modelsim.ini, vcom will proceed as expected. Yes, backslashes in file-names are allowed here.

If we give the same arguments to vsim, the error messages (and the actual behaviour) will be different:

vsim -modelsimini c:\tmp\modelsim.ini test
# vsim -modelsimini {{c:    mpmodelsim.ini}} test 
# ** Error: (vsim-7) Failed to open -modelsimini file "{c:  mpmodelsim.ini}" in read mode.
# 
# No such file or directory. (errno = ENOENT)
# Error loading design

vsim -modelsimini {c:\tmp\modelsim.ini} test
# vsim -modelsimini {{c:\tmp\modelsim.ini}} test 
# ** Error: (vsim-7) Failed to open -modelsimini file "{c:\tmp\modelsim.ini}" in read mode.
# 
# Invalid argument. (errno = EINVAL)
# Error loading design

The file-name argument will be processed the same way as before. But then the vsim script adds another pair of curly-braces around the expanded argument. This behavior should be considered as a bug, because it does not make any sense. vsim finally looks for a file called {c:\tmp\modelsim.ini} which can never be found on a Windows file system. In your error message the file-name is also enclosed by curly braces.

Crissycrist answered 4/5, 2016 at 15:48 Comment(1)
Earlier Modelsim command line interpreters appear to have considered back slashes as path separators until the advent of extended identifiers in VHDL '93. There was a switch to enable extended identifiers which required path separators use a forward slash. See ModelSim Command Reference 5.5e page CR-15, also CR-11 Extended identifiers where we find this is a command line argument limitation. It would appear making sense can be a matter of perspective.Pirogue
S
25

QuestaSim's vsim executable on Windows cannot cope with Windows paths (using \ as path delimiter sign) in the -modelsimini command line switch. The path needs to be in posix writing (using / delimiters).

As far as I can see, vcom has no problems with the correct path delimiter sign.

Siler answered 3/5, 2016 at 23:41 Comment(0)
C
5

It is questionable whether this should be considered as a bug or not because TCL requires that file names are specified with forward slashes instead of backward slashes. Of course, one would expect that file-names are handled the same way when calling vcom or vsim. So the solution from this viewpoint is to specify the path with forward slashes:

C:\Mentor\QuestaSim64\10.4c\win64\vsim.exe -do "do D:/git/PoC/sim/vSim.batch.tcl" -c -modelsimini D:/git/PoC/temp/precompiled/vsim/modelsim.ini -error 3473 -t 1fs test.arith_prng_tb

Checked it here with ModelSim 10.1d under Windows and a modelsim.ini in my temporary directory.


Some experiments under the vsim TCL console reveals that -modelsimini file-name is handled differently by the vcom and vsim commands. At first a backslash indicates an escape sequence, a \t in the file-name is expanded to a tab for example:

vcom -modelsimini c:\tmp\modelsim.ini test.vhdl
# ** Error: (vcom-7) Failed to open -modelsimini file "c:   mpmodelsim.ini" in read mode.
# 
# Invalid argument. (errno = EINVAL)
# D:/altera/13.1_web/modelsim_ase/win32aloem/vcom failed.

To prevent this, the argument can be put in curly braces {} for example:

vcom -modelsimini {c:\tmp\modelsim.ini} test.vhdl
# ** Error: (vcom-7) Failed to open -modelsimini file "c:\tmp\modelsim.ini" in read mode.
# 
# No such file or directory. (errno = ENOENT)
# D:/altera/13.1_web/modelsim_ase/win32aloem/vcom failed.

I specified a non-existent file, so that one can see the expansion. If I create the file c:\tmp\modelsim.ini, vcom will proceed as expected. Yes, backslashes in file-names are allowed here.

If we give the same arguments to vsim, the error messages (and the actual behaviour) will be different:

vsim -modelsimini c:\tmp\modelsim.ini test
# vsim -modelsimini {{c:    mpmodelsim.ini}} test 
# ** Error: (vsim-7) Failed to open -modelsimini file "{c:  mpmodelsim.ini}" in read mode.
# 
# No such file or directory. (errno = ENOENT)
# Error loading design

vsim -modelsimini {c:\tmp\modelsim.ini} test
# vsim -modelsimini {{c:\tmp\modelsim.ini}} test 
# ** Error: (vsim-7) Failed to open -modelsimini file "{c:\tmp\modelsim.ini}" in read mode.
# 
# Invalid argument. (errno = EINVAL)
# Error loading design

The file-name argument will be processed the same way as before. But then the vsim script adds another pair of curly-braces around the expanded argument. This behavior should be considered as a bug, because it does not make any sense. vsim finally looks for a file called {c:\tmp\modelsim.ini} which can never be found on a Windows file system. In your error message the file-name is also enclosed by curly braces.

Crissycrist answered 4/5, 2016 at 15:48 Comment(1)
Earlier Modelsim command line interpreters appear to have considered back slashes as path separators until the advent of extended identifiers in VHDL '93. There was a switch to enable extended identifiers which required path separators use a forward slash. See ModelSim Command Reference 5.5e page CR-15, also CR-11 Extended identifiers where we find this is a command line argument limitation. It would appear making sense can be a matter of perspective.Pirogue

© 2022 - 2024 — McMap. All rights reserved.